I cannot understand what "ignition" means.
Persistency offers mechanisms to Adaptive Applications to store information in the non-volatile memory of a machine. The data is available over boot and ignition cycles.
I think, "ignition" means that the data is loaded from persistent memory like HDD, SSD. Is it right?
In this context it means power off / power on.
Related
In the middle of this page (https://github.com/ultraembedded/riscv), there is a block diagram about the core, I really do not know what is TCM doing in the same block with the Icache ? Is it an optional thing to be inside the CPU ?
Some embedded systems provide dedicated memory for code and/or for data. On some of these systems, Tightly-Coupled Memory serves as a replacement for the (instruction) cache, while on other such systems this memory is in addition to and along side a cache, applying to a certain portion of the address space. This dedicated memory may be on the chip of the processor.
This memory could be some kind of ROM or other memory that is initialized somehow prior to boot. In any case, TCM typically isn't backed by main memory, so doesn't suffer cache misses and the associated circuitry, usually also has high performance, like a cache when a hit occurs.
Some systems refer to this as Instruction Tightly Integrated Memory, ITIM, or Data Tightly Integrated Memory, DTIM.
When a system uses ITIM or DTIM, it performs more like a Harvard architecture than the Modified Harvard architecture of laptops and desktops.
The cache has no address space. CPU does not ask for data from the cache, it just asks for a data, then the memory controller first checks the cache if the data is present in the cache. If it is in the cache, data is fetched, if not then the controller checks the RAM. All processor does is ask for data, it does not care where the data came from. In the case of TCM, the CPU can directly write data to TCM and ask data from TCM since it has a specific address. Think of TCM as a RAM that is close to the CPU.
I'm trying to decide between using the Heroku Crane PostgreSQL database ($50/month - https://postgres.heroku.com/pricing) or setting up a Linode 1GB Ram / 8 CPU / 48GB Storage / 2TB Transfer instance with PostgreSQL installed ($20/month - https://www.linode.com/).
I know that from a management perspective, using Heroku Crane PostgreSQL would be much easier, as everything is managed with security and backups taken care of.
What I was curious about is how performance of the two databases would compare. With the Linode 1GB / 8 CPU instance, only my database will be used on it. I see with Heroku Crane that it says it only gets 400 MB RAM. It also isn't clear with Heroku Crane how many CPU's I get and whether its a dedicated instance.
Does the Heroku DB manages the RAM/Cache of the DB more efficiently? Its unclear to me whether the Linode PostgreSQL instance would automatically use the 1GB RAM available to it efficiently, or if it would require custom setup on my part to ensure the DB is loaded into RAM.
If it is that the Heroku DB would be less performant for the money, but is a better deal because security, backups and management are taken care of, that is probably acceptable, I just want to understand the tradeoffs.
Thanks for any info people can provide. I'm new to DB management, and have been using a Linode 1GB instance with PostgreSQL installed for development and testing, but now that I'm going to production, am questioning whether to move over to Heroku Crane. Also, not sure if this matters, but my server is hosted through Heroku web instances.
Lower Heroku plans are on a shared server partitioned into containers with LXC. The details are on Heroku's site. Your plan appears to be one of them.
This can actually be a win as discussed in this question if you happen to be on an instance where other users aren't putting much load on the server. It makes your performance less predictable though.
The only good way to characterize performance is to benchmark with a simulation of your production workload.
Whether the RAM actually matters or not depends on your data. If your frequently accessed data and indexes fit in RAM on one machine, but not on another, then the RAM difference will make a huge difference. If the data fits in RAM on both hosts there's little benefit to adding RAM. If the hot data won't fit in RAM on either machine then disk I/O performance becomes more important than RAM, mostly random read I/O and the fsync() flush rate.
So. Benchmark with a simulation of your workload with your expected data size and see.
Heroku discusses cache in more detail here.
(I work for another company in the same kind of space as Heroku, per my profile, so I'm reluctant to express a strong opinion one way or the other).
I have a question,
is it possible for multiple processor machine to access data from RAM ( single ram system ) ?
for eg machine has 2 processors p1, p2 which are executing in parallel , is it possible that they access same ram for read and write ( ofcos write is not on same location )
i understand that in multi core machines it will not be possible since data bus is shared.
As long as the RAM is mapped to all cores or processors (such as in a multi-threaded application) it may be accessed from any core or processor.
There is no difference if you're discussing single processor/single core, single processor/multi-core, multi-processor/(each with a) single-core or multi-processor/multi-core. Since they have no system RAM of their own - the RAM in caches is not system RAM - the only RAM available to all of them is the system RAM.
The only difference between multi-processor/single core (as in older systems) and single processor/multi-core (modern systems) is that the former needs to coordinate RAM accesses with off-chip logic whereas for the latter all coordination is on-chip and sometimes even on-die which of course results in much faster and more electronically efficient RAM accesses.
In the case of AMD's multi-processor/multi-core solutions each processor owns part of the system RAM. The processors themselves are interconnected with high-speed data (HyperTransport) channels to facilitate accesses to RAM not owned by the processor accessing it.
In any case it is up to the programmer to decide how the processors/cores access the RAM. Sure they can read and/or write to the same location if that is what the programmer wants.
Can anyone highlight ways by which inter-core communication can be reduced in a NUMA multicore architecture. Case study Intel NEHALEM micro architecture.
The Nehalem processor uses QuickPath Interconnect (QPI) for inter-processor/node/package communication. In a NUMA system each node has its own local memory, which is shared with other nodes in the system. When the working set of a program fits in the L1 cache and is read-only then it doesn't matter much which NUMA node owns the memory. Communication between NUMA nodes is necessary when a core gets a cache miss and the memory is owned by another node. However, this doesn't mean that it is slower to access memory owned by another node, it depends on whether the other node has it cached in the cache associated with its local memory, what Intel calls the Last Level Cache (LLC). Access by a core to a memory location that is local to that node is faster than access to memory owned by another node, but only if it misses in the LLC on both nodes. It is faster to access memory that hits in the LLC on another node than it is to go to memory on the local node, that is because memory is so much slower than the CPU and QPI is optimized for this sort of communication. Most systems don't bother trying to reduce inter-processor communication because, as you can imagine, it is not an easy problem - it requires setting affinity of threads to cores, setting affinity of the memory working set of that thread to the local memory of that node. You can read more about this in Drepper Ulrich's paper, search for NUMA. In this paper Ulrich refers to QPI as Common System Interface (CSI), which was the Intel name for QPI before announcement.
I am considering developing an application with a Cassandra backend. I am hoping that I will be able to run each cassandra node on commodity hardware with the following specs:
Quad Core 2GHz i7 CPU
2x 750GB disk drives
16 GB installed RAM
Now, I have been reading online that the available disk-space for Cassandra should be double the amount that is stored on the disks, which would mean that each node (set up in a RAID-1 configuration) would be able to store 375 GB of data, which is acceptable.
My question is this if 16GB RAM is enough to efficiently serve 375 GB of data per node. The data in the application developed will also be fairly time-dependant, such that recent data will be the data most read from the database. In fact, most of the data will be deleted after about 6 months.
Also, would I assign Cassandra a Heap (-Xmx) close to 16 GB, or does Cassandra utilize off-heap memory ?
You should not set the Cassandra heap to more than 8GB; bigger than that, and garbage collection will kill you with large pauses. Cassandra will use the buffer cache (like other applications) so the remaining memory isn't wasted.
16GB of RAM will be enough to serve the data if your hot set will all fit in RAM, or if serving rate can be served off disk. Disks can do about 100 random IO/s, so with your setup if you need more than 200 reads / second you will need to make sure the data is in cache. Cassandra exports good cache statistics (cassandra-cli show keyspaces) so you should easily be able to tell how effective your cache is being.
Do bear in mind, with only two disks in RAID-1, you will not have a dedicated commit log. This could hamper write performance quite badly. You may want to consider turning off the commit log if it does affect performance, and forgo durable writes.
Although it is probably wise not to use a really huge heap with Cassandra, at my company we have used 10GB to 12GB heaps without any issues so far. Our servers typically have at least 48 GB of memory (RAM is cheap -- so why not :-)) and so we may try expanding the heap a bit more and see what happens.