PrimoCache version: 2.2.0
Cache Settings: vary
Windows OS: 10
Hardware Information (CPU/Motherboard/Memory/Harddisks): 2 x Xeon E5620 / Lenovo C20 / 8GB / 2 x 1TB RAID0 + 64GB SSD
Description:When I create a new cache Primo lets me create a 3,5GB L1 + full SSD cache at 4k which equals 3,22GB overhead and 0,5GB of free memory. But then when I decrease cache size to say 512MB L1 + 1GB SSD at 8k, it won't let me come back to full possible size - it says there's not enough memory even though there is. For example after such a low setting it won't let me increase the cache size to even 2GB L1 + 32GB SSD at 8k - not enough memory even though at first cache creation it let me create even bigger cache.
There seem to be some problems with calculations, please fix it.
Allowed size of cache inconsistencies Topic is solved
Allowed size of cache inconsistencies
Last edited by rutra80 on Thu Feb 18, 2016 11:13 am, edited 1 time in total.
Re: Allowed size of cache inconsistencies
Did you add some new volumes to this cache task during reconfigurations? We made some quick tests, but we don't see the issue you reported.
Re: Allowed size of cache inconsistencies
No, nothing was added. It happens even when I do nothing else but resize cache - I can create big cache, then immediately make it smaller, and then immediately try to make it bigger and it won't let me.
Re: Allowed size of cache inconsistencies
I suspect 2 possibilities:
1. You query wrong kind of free memory (maybe free physical memory instead of free system memory excluding buffers?). It's a dual-socket NUMA system so maybe you're querying free memory of 1 CPU node only?
2. The calculations are wrong - they don't take into account memory currently used by Primo caches. If ATM I have so much cache that there's 8GB RAM - 3GB cache - 3.5GB overhead - 1GB sys+apps = 0,5GB of free memory, it won't let me reduce the cache size to 2GB because it thinks that 0,5GB of free memory is not enough, it says: hey, you would need 8GB RAM - 2GB cache - 3GB overhead - 1GB sys+apps = 2GB free memory but you currently only have 0,5GB so nope, sorry it's not possible
What helps here is to temporarily set the block size to 512KB so there's more free memory, then it lets me change the size of cache without lack of memory complaints, and then I can switch it back to 4KB.
1. You query wrong kind of free memory (maybe free physical memory instead of free system memory excluding buffers?). It's a dual-socket NUMA system so maybe you're querying free memory of 1 CPU node only?
2. The calculations are wrong - they don't take into account memory currently used by Primo caches. If ATM I have so much cache that there's 8GB RAM - 3GB cache - 3.5GB overhead - 1GB sys+apps = 0,5GB of free memory, it won't let me reduce the cache size to 2GB because it thinks that 0,5GB of free memory is not enough, it says: hey, you would need 8GB RAM - 2GB cache - 3GB overhead - 1GB sys+apps = 2GB free memory but you currently only have 0,5GB so nope, sorry it's not possible
What helps here is to temporarily set the block size to 512KB so there's more free memory, then it lets me change the size of cache without lack of memory complaints, and then I can switch it back to 4KB.
Re: Allowed size of cache inconsistencies
Here's how it looks when I try to reduce L1 from 3GB to 2GB.
- Attachments
-
- ram.png (93.04 KiB) Viewed 6134 times
Re: Allowed size of cache inconsistencies
Thank you very much for the detailed information!
Yes, you're right. We take into count the memory that is currently used for L1 cache, but forgot the overhead memory. We'll fix this bug in the next version.
Yes, you're right. We take into count the memory that is currently used for L1 cache, but forgot the overhead memory. We'll fix this bug in the next version.
-
- Level 1
- Posts: 3
- Joined: Sat Feb 27, 2016 12:27 pm
Re: Allowed size of cache inconsistencies
It happens to me too.
What it is is when calculating the RAM, it does not subtract cache that will be replaced.
Like if you have 16 total and cache is at 4 increasing to 8 program seems to think 4+8 and deciding too much ram,before it considers than 4 ill be same RAM.
Numbers not scaled well but that is what seems to happen.
BUT it may have to make the new cache before deleting the old.
or simultaneously.
So you can set it much lower, then increase it.
It seems the new RAM cache is not adding to, but creating a New RAM cache,
Dammit Jim I am a physicist not a Computer programmer.
What it is is when calculating the RAM, it does not subtract cache that will be replaced.
Like if you have 16 total and cache is at 4 increasing to 8 program seems to think 4+8 and deciding too much ram,before it considers than 4 ill be same RAM.
Numbers not scaled well but that is what seems to happen.
BUT it may have to make the new cache before deleting the old.
or simultaneously.
So you can set it much lower, then increase it.
It seems the new RAM cache is not adding to, but creating a New RAM cache,
Dammit Jim I am a physicist not a Computer programmer.
Re: Allowed size of cache inconsistencies
Well why there isn't a new release already?
I guess it would be more beneficial for everyone if you reduced the trial time to 7-14 days and release more often...
I guess it would be more beneficial for everyone if you reduced the trial time to 7-14 days and release more often...
-
- Level SS
- Posts: 477
- Joined: Wed Oct 06, 2010 11:10 pm
Re: Allowed size of cache inconsistencies
Not really, it would make it harder for people to evaluate it properly, and frequent re-installs mean more work for users generally.rutra80 wrote:I guess it would be more beneficial for everyone if you reduced the trial time to 7-14 days and release more often...
This problem can be worked around (by deleting the cache and recreating from scratch) so it seems to be more an annoyance rather than something requiring an urgent fix.
Re: Allowed size of cache inconsistencies
14 days is more than enough to evaluate on desktops, server trial could be a month long.
The way it is currently makes them hesitate with updates because it gives everyone another month of free ride and no profit for Romex - if they released more frequently than every 40 days, PrimoCache would be effectively a freeware. That way you have to wait several months for any update so they can have any profit at all.
There's quite a lot of bugs including critical ones like data corruption and system crashes. Not to mention many features that could be added to make the product even more interesting.
The way it is currently makes them hesitate with updates because it gives everyone another month of free ride and no profit for Romex - if they released more frequently than every 40 days, PrimoCache would be effectively a freeware. That way you have to wait several months for any update so they can have any profit at all.
There's quite a lot of bugs including critical ones like data corruption and system crashes. Not to mention many features that could be added to make the product even more interesting.