This question already has answers here:
For Write-Back Cache Policy, why data should first be read from memory, before writing to cache?
(2 answers)
Why data is fetched from main memory in Write Allocate cache policy
(1 answer)
MESI protocol. Write with cache miss. Why needs main memory value fetch?
(1 answer)
Closed 10 months ago.
I was just wondering about in write allocation policy of caches, first we access data from main memory and put into cache and then update in the cache. If anyway we use write back policy to counter cache coherency then after updating data into cache we don't have to update simultaneously in the main memory. But I am not able to understand why are we fetching old data from memory to cache first and then updating in case of write miss and we use write allocation with write back policy, why not directly put that data into cache itself.
Related
what is meant by cache invalidate operation and cache flush operation in cache memory ?
please explain as if explaining to a layman, as I'm a very newbie to cache-related stuff.
I have a PERSISTENT cache configured like this :-
<region name="stock-hist" refid="PARTITION_PERSISTENT" >
<region-attributes disk-store-name="myOverflowStore" disk- synchronous="false">
<partition-attributes local-max-memory="1024" />
<eviction-attributes>
<!-- Overflow to disk when 100 megabytes of data reside in the
region -->
<lru-memory-size maximum="100" action="overflow-to-disk"/>
</eviction-attributes>
</region-attributes>
The problem is that when I storing say 8 GB of data the cache crashes due to too much memory. I do not want that to happen. Like I need the data to overflow to disk when it is beyond 100MB, but get it back to cache if I try to access it. I also want persistent cache.
Also in case I write behind to a database, how can I evict data after sometime.
How does this work?
This is a use-case for which an In-Memory Data Grid is not intended. Based on the problem that you are describing, you should consider using a relational DB OR you should increase memory to use an IN-MEMORY Data Grid. Overflow features are intended as a safety valve and not for "normal" use.
I do not understand when you say that "it" crashes due to "too much" memory since it obviously does not have "enough" memory. I suspect that there is not have sufficient disk space defined. If you think not, check your explicit and not implicit disk allocations.
As for time-based eviction/ expiration, please see "PARTITION_HEAP_LRU" at: http://gemfire.docs.pivotal.io/docs-gemfire/latest/reference/topics/region_shortcuts_reference.html
This question already has answers here:
Why do you have to use copy_to_user()/copy_from_user() to access user space from the kernel?
(2 answers)
Closed 9 years ago.
If kernel can access user space why do we need copy_from_user to copy data in kernel memory, why it just cant access user space data? is it for performance?
Kernel and user space do not necessarily have the same address space. They can be entirely separate, requiring special CPU instructions to move data between them.
The other important point is that the kernel needs to access user space with user permissions, i.e. if the user space program accessing that address would fail, then copy_from_user() will also fail, even if the kernel could access that address by itself.
Apart from general access violations, permission failure can also include a page not being in memory because it resides on disk. This may require some kind of special set up since normally the kernel does not use swappable memory.
I've setup the enterprise library caching counters using Perfmon. However all I can see is number of entries in cache.
COuld someone please help me if there's way to find out the size of the cached object so that I can specify correct value for Max num of items to be cached and removed etc?
Also, what does Missed Caches really means as I see quiet large number of misses although my web application is working as expected. Do I need to worry about this counter?
Enterprise Library Caching does not provide the size of the cache or the size of objects in the cache.
There are various approaches to finding the object size that you could use to try to tune the cache size. See:
Find out the size of a .net object
How to get object size in memory?
A Cache Miss is when an item is attempted to be retrieved from the cache but the key is not found in the cache. Usually when this happens you would add the item to the cache. This is not usually alarming since for a cache with no backing store it will be empty at first so initially you would see cache misses but misses should decrease as the cache is loaded (unless of course items expire and are removed from the cache).
Question 1
I am building/searching for a RAM memory cache layer for my server. It is a simple LRU cache that needs to handle concurrent requests (both Gets an Sets).
I have found https://github.com/pmylund/go-cache claiming to be thread safe.
This is true as far as getting the stored interface. But if multiple goroutines requests the same data, they are all retrieving a pointer (stored in the interface) to the same block of memory. If any goroutine changes the data, this is no longer very safe.
Are there any cache-packages out there that tackles this problem?
Question 1.1
If the answer to Question 1 is No, then what would be the suggested solution?
I see two options:
Alternative 1
Solution: Storing the values in a wrapping struct with a sync.Mutex so that each goroutine needs to lock the data before reading/writing to it.
type cacheElement struct { value interface{}, lock sync.Mutex }
Drawbacks: The cache becomes unaware of changes made to data or might even have dropped it out of the cache. One goroutine might also lock others.
Alternative 2
Solution: Make a copy of the data (assuming the data in itself doesn't contain pointers)
Drawbacks: Memory allocation every time a cache Get is performed, more garbage collection.
Sorry for the multipart question. But you don't have to answer all of them. If you have a good answer to Question 1, that would be sufficient for me!
Alternative 2 sounds good to me, but please note that you do not have to copy the data for each cache.Get(). As long as your data can be considered immutable, you can access it with many multiple readers at once.
You only have to create a copy if you intend to modify it. This idiom is called COW (copy on write) and is quite common in concurrent software design. It's especially well suited for scenarios with a high read/write ratio (just like a cache).
So, whenever you want to modify a cached entry, you basically have to:
create a copy of the old cached data, if any.
modify the data (after this step, the data should be considered immutable and must not be changed anymore)
add / replace the existing element in the cache. You could either use the go-cache library you have pointed out earlier (which is based on locks) for that, or write your own lock-free library that simply swaps the pointers to the data element atomically.
At this point any goroutine that performs a cache.Get operation will get the new data. Existing goroutines however, might still be reading the old data. So, your program might operate on many different versions of the same data at once. But don't worry, as soon as all goroutines have finished accessing the old data, the GC will collect it automatically.
tux21b gave a good answer. I'll just point out that you don't have to return pointers to data. you can store non pointer values in your cache and go will pass by value which will be a copy. Then your Get and Set methods will be safe since nothing can actually modify the cache contents.