DynamicSaveStrategy

[XeroX]

Hello,
does anyone know why the DynamicSaveStrategy has been excluded from SaveStrategy evaluation?

https://github.com/Xeroxxx/ServUO/blob/patch-cosmetics/Server/Persistence/SaveStrategy.cs

Changed my Server to Dynamic, had no issues.

Cheers

 

[Voxpire]

The implementation for it was never fully completed or tested according to Mark the last time I asked him about it.

If I recall correctly, it holds the potential to cause a race condition that results in process dead-lock, when saving larger world databases.

Also, I think I was the one who excluded it from production in the code, maybe I should have left comments, lol.

 

[XeroX]

Will check that with a huge worldsave over several days.
[doublepost=1487687693][/doublepost]@Voxpire
Do you have any hints about size for me?

Currently testing wit 6.800.000+ Items and 4000 mobiles.

However what I can already say, DynamicSaveStrategy is more than 400% slower than DualSaveStrategy on a Dual Quad-Core Xeon System (2 NUMA à 4 physical Cores without HT).

 

[Voxpire]

@XeroX 6.8 mil is good enough to produce relevant results.

I'm surprised that it ended up being slower though.

 

[XeroX]

Disastrous

50% more RAM usage with DynamicSaveStrategy.
[doublepost=1487713048][/doublepost]Wow, Parallel Save Strategy....after 6 hours.

Even more slow than Dynamic (40-45seconds), RAM stays, CPU goes 90% because of threading and parallel usage.

So...Dual is stable and simply the best you can go with. No matter how much cores you've (okay...at least two).

 

[Grimoric]

I did some digging in my SQL server and found this links.
The first post explains that DynamicSaveStrategy was a experiment to take over for the not so good working ParallelSaveStrategy.

Experimental Feature: DynamicSaveStrategy [2010-12-18]

Quad core issue or am i screwed? [2012-10-01]

Better storage engine [2008-05-10]

Quicker Save Times (Discussion/Etc) [2011-06-21]

- Grim

 

[XeroX]

Hey Grim,
thanks this is highly interesting. It even describes the reason for higher memory usage.

Divides up the list of that type into large chunks. Each of these chunks gets it's own thread. Each of these threads Serialize to their own MemoryStream. As each of these chunks complete (in parallel), we add each completed memory stream to a queue, to be processed by another Thread.

Secondly I'm still surprised about the bad performance of parallel save strategy. I can not exclude this is a HDD performance issue but still not what I expected.

I've attached all missing save strategys just for completion.