The task is to count "cache writes" during some algorithm work.
So what's cache write?
Is it a process when data is written to the cache or what?
It should be in your lecture notes or textbook.
But yes, a cache write is when you write to the cache. One of the problems with a cache write is that in order to be in a state where you have a cache write, it means you didn't already have the data you wanted in the cache.
Related
I apologize if this has already been answered, I just came across some textbook references that seem to be using the terms "page cache" and "disk cache" as separate entities, but I always was under the impression that they were the same thing.
The link below answers your question
https://www.quora.com/What-is-the-difference-between-memory-cache-and-disk-cache-in-Chrome
A page cache is used to speed up access to images and data on disk. It is used to cache the logical contents of a file a page at a time and is accessed via the file and offset within the file. As pages are read into memory from disk, they are cached in the page cache.
I am very new to Redis. I've implemented caching in our application and it works nicely. I want to store two main data types: a directory listing and file content. It's not really relevant, but this will cache files served up via WebDAV.
I want the file structure to remain almost forever. The file content needs to be cached for a short time only. I have set up my expiry/TTL to reflect this.
When the server reaches memory capacity is it possible to priorities certain cached items over others? i.e. flush a key, flush a whole database or flush a whole instance of Redis.
I want to keep my directory listing and flush the file content when memory begins to be an issue.
EDIT: Reading this article seems to be what I need. I think I will need to use volatile-ttl. My file content will have a much shorter TTL set, so this should in theory clear that first. If anyone has any other helpful advice I would love to hear it, but for now I am going to implement this.
Reading this article describes what I needed. I have implemented volatile-ttl as my memory management type.
I have a specific cache system in Redis.
The content of this system is quite volatile, and values get added and removed all the time. I want to keep the "used" keys in memory as much as possible, while getting the old ones to expire.
Each request can require hundreds of keys from the cache.
I'm aware that I could set a "long enough" expire time, and just dealt with the Cache misses, but I'd like to have as little misses as possible.
Currently I'm doing something like this, when I'm writing / reading to the cache (pseudo code)
# write
write(key, value)
expire(key, ttl)
# read
read(key)
expire(key, ttl)
I can optimise the read by using pipelining.
Now this still seems like it's not the best way of doing it.
Could someone give me a better strategy?
If you can live with the (current) resolution of 10 seconds then the OBJECT IDLETIME command would let you get a better sense of what has not been used for a while (in blocks of 10 seconds)
> SET X 10
OK
> OBJECT IDLETIME X
10
I would create a script (https://redis.io/commands/script-load) that does this atomically and faster directly on the server side and then use it with EvalSha (https://redis.io/commands/evalsha).
This saves the extra round trip on each of the commands.
Alternatively you can implement a similar algorithm to the LRU cache that Redis runs when it's out of space (https://redis.io/topics/lru-cache) - every once in a while get random keys and remove them if they're too old for you, optionally loop until you get a long sequence of new keys.
If what you are trying to achieve is a perfect LRU cache (Least Recently Used), you can tune Redis to behave like this globally, here is a link about Redis as LRU:
http://oldblog.antirez.com/post/redis-as-LRU-cache.html
Note that it is using maxmemory property on redis and the eviction rule is global unless you look at volatile LRU: How to make Redis choose LRU eviction policy for only some of the keys?
You are using a manual solution for eviction with custom expiration / TTL which is the most powerful solution, but maybe you can simplify your configuration and have a better predictable cache in memory size with this solution.
In a processor, what happens to the cache when the operating system replaces a page, if there is not enough space to hold all running processes' pages in memory? Does it need to flush the cache on every page replacement?
Thanks in advance for your replies.
When a page is swapped in, the contents are read off the disk and into memory. Typically this is done using DMA. So the real question is, "How is the cache kept coherent with DMA?". You can either have DMA talk to the cache controller on each access, or make the OS manage the cache manually. See http://en.wikipedia.org/wiki/Direct_memory_access#Cache_coherency.
I am not 100% sure of what happens in details, but caches and virtual memory using paging
are similar: both are divided in "pages".
The same way that only one page needs to be replaced in a page fault, only one line of
the cache needs to be replaced when it occurs a miss on the cache. The cache has
several "pages" (lines), but only the problematic page will be replaced.
There are other things that I do not know if takes part on such replacements: cache size,
cache coherency - write-through/back and so on. I hope someone else can give you a more detailed answer.
I see some variables named 'dirty' in some source code at work and some other code. What does it mean? What is a dirty flag?
Generally, dirty flags are used to indicate that some data has changed and needs to eventually be written to some external destination. It isn't written immediate because adjacent data may also get changed and writing bulk of data is generally more efficient than writing individual values.
There's a deeper issue here - rather than "What does 'dirty mean?" in the context of code, I think we should really be asking - is 'dirty' an appropriate term for what is generally intended.
'Dirty' is potentially confusing and misleading. It will suggest to many new programmers corrupt or erroneous form data. The work 'dirty' implies that something is wrong and that the data needs to be purged or removed. Something dirty is, after all undesirable, unclean and unpleasant.
If we mean 'the form has been touched' or 'the form has been amended but the changes haven't yet been written to the server', then why not 'touched' or 'writePending' rather than 'dirty'?
That I think, is a question the programming community needs to address.
Dirty could mean a number of things, you need to provide more context. But in a very general sense a "dirty flag" is used to indicate whether something has been touched / modified.
For instance, see usage of "dirty bit" in the context of memory management in the wiki for Page Table
"Dirty" is often used in the context of caching, from application-level caching to architectural caching.
In general, there're two kinds of caching mechanisms: (1) write through; and (2) write back. We use WT and WB for short.
WT means that the write is done synchronously both to the cache and to the backing store. (By saying the cache and the backing store, for example, they can stand for the main memory and the disk, respectively, in the context of databases).
In contrast, for WB, initially, writing is done only to the cache. The write to the backing store is postponed until the cache blocks containing the data are about to be modified/replaced by new content.
The data is the dirty values. When implementing a WB cache, you can set dirty bits to indicate whether a cache block contains dirty value or not.