View Full Version : New Shared Memory
Chrono
02-28-2013, 04:09 AM
With the latest overhaul to shared memory in the code, I was just curious as to what advantages it has over the last system? As it seems like a huge change.
trevius
02-28-2013, 04:33 AM
I imagine KLS will chime in on this thread, but here is the changelog update about it:
== 02/27/2013 ==
KLS: Changed how shared memory works:
Instead of System V/windows pagefile shared memory we now have shared memory that's backed by the filesystem.
What that means is basically instead of EMuSharedMem(shared library) we now have shared_memory(executable),
shared memory will be persistent between runs until you delete or reload it using the shared_memory executable.
STEPS FOR PEOPLE WHO CAN'T BE BOTHERED TO FIGURE IT OUT:
1) Create a directory in the place you run world/zone named shared and make sure files can write there.
2) Run the shared_memory executable from the same place you run world/zone
(it's basically doing the loading we would do on startup so will take a moment).
3) Run world/zone/whatever
The biggest advantage is to people like me who have to restart zone over and over and over while developing incrementally. Which took me about a minute each time (guh). Now I only need to process the data when it changes. Which means cold zone boot ups go from about 60 seconds to about 3 seconds.
A secondary reason (and the main motivator for me) was to make it easier to put things into shared memory if we need to. It was such an utter pain before that no one bothered to even try. It's pretty easy now though.
And of course never having to run cleanipc ever again is a nice perk.
Drajor
02-28-2013, 08:41 AM
KLS will this have an impact on the physical memory footprint, or the speed of fetching data from shared memory? I am interested in the physical memory because earlier designs of my server had millions of items and I started to run out of memory at about 900,000 items. The design has changed to use fewer items now.
It does have an impact on the memory footprint of items. Before we had a system where if you had x items with y being the max item id you allowed(set by a compile option), in that system you stored y items. The default being 300000.
Now you store x items with z number of offsets (4 bytes each), where z is the actual max item id.
So people who have tightly packed item ids will see memory increase slightly, most people will see a reduction in memory. People using PEQ's DB for instance will see items use about 1/3 the memory if they had been using the default settings.
Drajor
03-01-2013, 05:46 AM
Interesting! I am going to have to play around with this because on my server I allocate memory for items differently. Due how I create content I have tightly packed IDs...
KingMort
03-03-2013, 04:21 PM
Interesting changes I like it thank you. I had no clue what was going on however I had to sort of search the forums to figure out why my server wouldn't start after updating to latest build (after figuring out how to do so)
You guys rock though :) Keep up the good work!
Morty
Irreverent
04-14-2013, 10:33 AM
Is there a way to take loot tables out of it? Seemed so much easier/faster to have them dynamically pulled from the database when debugging/changing them.
I can understand items
demonstar55
04-14-2013, 03:14 PM
$ ./shared_memory loot
Will just reload the loot tables.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.