Pesistant Storage - Interim Solutions

[AcadiusLost]

See the edit to the stickied topic re: P-storage. The fix is in, and holding.

[NickD]

Well done.

What was the fix?

[Kest]

spoonfeeding

[AcadiusLost]

What was the fix?

It started to become clear that the problem was tied to how big the TSM module had gotten, specifically it's memory footprint. BG doesn't have the symptoms, much smaller mod. Exodus' Amn server (on the same core/perisistency scripts) didn't have the p-storage problems before, but has recently started to exhibit them (their module is getting close to TSM in size now). This prompted me to re-test using a pared-down version of TSM which had a smaller memory footprint (by deleting a pile of large exteriors), which turned out to work (though there was still a massive lag hit during the first write operation).

Watching the pagefile usage in Task Manager, I was reminded of a strange but recurrent phenomenon, whereby the first object write to the native campaign DB would cause a big jump in pagefile/memory use (maybe 20-40% increase in overall size), with subsequent read and write operations running smoothly (the pagefile useage would stay high, though). I discussed the finding with Wynna, who wanted me to narrow down the threshold size that was still workable for p-storage, so she could try to trim down the mod sufficiently. In testing a nearly full-sized module, I was able to get a successful DB write with a PC who logged into an interior adjacent to a pstorage object, immediately after a module reset (fresh module, 1 player on, no ATs performed yet, no spawns in area (or active in the module yet), etc. Basically best-case scenario. Seeing that the one successful write was all that was necessary to get stability for the remainder of the module's runtime, we hit on a plan to try to "pre-initialize" the campaign DB.

OnModuleLoad, we added a script which creates a single object at the start location. Arbitarily, I decided to have it make a spoon. The script then stores the spoon in an object database (causing a write operation), and subsequently deletes the in-module copy. The net effect is to get the major lag/performance/memory hit of that first write operation out of the way before anyone has opportunity to log in, such that things are stable and functional for subsequent campaign DB operations elsewhere on the server.

Four lines of code, including the WriteTimestampedLogEntry("There is no spoon"). TSM takes an extra minute or two to load now while it recovers from that first DB write, but seems to be working otherwise.

And so I get to avoid revamping the entire p-storage code to work with BLOBs for a few more months at least, with any luck.

[Rotku]

Now that's out of the box thinking. Nice work, AL

[Ithildur]

Brilliant. The simplest and most elegant solutions are often the best. Gotta love the spoon bit.

[Brother Humphrey]

Just goes to show that spooning afterwards really does promote harmony

[HEEGZ]

Just goes to show that spooning afterwards really does promote harmony

[hollyfant]

Spoon!

[dob85y]

AL and Wynna,

Your geniuseseses has once again made all things right with the world of ALFA.

Thank you