Romex Software Forum

I haven't tried that - it's a good idea. I'll also try to trigger this with ordinary activity (like copying files) without the app running at all.

I have been able to determine with high likelihood that the problem is triggered by a burst of uncached reading activity from the same underlying drive. If I can confirm this, it should be possible to solve it by activating a read cache as well. So far I've gotten around the problem by artificially limiting the input to the app which, in turn, limits the read activity.

Could you tell me what causes PrimoCache to make writes urgent? Under normal circumstances (no sign of thrashing) I get only about 1% urgent writes, which makes me wonder about this.

Re. sending the app, it's not mine and it would be complicated, but if this persists with no other clues I'll try to figure something out.

Thanks.

mell111 wrote: ↑Tue Jan 22, 2019 7:20 amCould you tell me what causes PrimoCache to make writes urgent? Under normal circumstances (no sign of thrashing) I get only about 1% urgent writes, which makes me wonder about this.

Typically that happens when the cache is full and more writes are coming into it than it can push out.

Hmm. Given that in my configuration the cache is write-only, is 15 GB and the max writing speed is < 50 MBps while the underlying disk can write > 100 MBps, that shouldn't happen. It's possible that there are very brief thrashing intervals here and there that would trigger this. This is such a small percentage that it's not a problem. Can Support confirm this? Thanks.

Regarding urgent writes here, the only thing I can confirm is that there is at least one latency period in which PrimoCache cannot flush all deferred write-data in time, especially meanwhile there were new write-data coming.
We can temporarily ignore urgent writes here because I think it might be a result of this slow writing issue you reported.