21–30 of 48 posts
A bit ironic since this is an article about reducing blocking for improving performance.
In practice, I've seen plenty of errant bugs because of race conditions in sites that start to come under heavy load. I wish more people would take the time to understand how their platforms work. That said, I've really come to appreciate the node.js approach.
I don't think that a load of 172 is a good idea. I know this is a benchmark that is measuring how fast you can go ideally but in production the question is how fast you can go with with keeping the latency within the SLA. As a general rule you want to run your boxes around 1 normalized load ( load / # of CPU cores). The rest of the article is pretty nice.
Remember that processes in (D)isk Wait state count towards the load average even though they are not running or runnable.
I don't think that a load of 172 is a good idea. I know this is a benchmark that is measuring how fast you can go ideally but in production the question is how fast you can go with with keeping the latency within the SLA. As a general rule you want to run your boxes around 1 normalized load ( load / # of CPU cores). The rest of the article is pretty nice.
Having load average exceed core count isn't necessarily a sign of an imminent cascade failure. IIRC it's just a count of the number of processes that could run, but are waiting for a timeslice. A particular server and application might be perfectly fine with a load average that is 10 times the number of cores, as long as the average remains stable and the server is meeting response requirements.
Linux has POSIX aio syscalls which seems to work. At least Informix and Oracle rely on them.
Linux kernel aio will often still block when dealing with the page cache even if you request nonblocking. The workaround for this is to use O_DIRECT, which is okay for databases that do their own cache management but not for something like nginx (which is depending on the OS cache). Glibc's posix aio (aio_*(3)), on the other hand, does not use Linux's kernel aio AFAIK. It probably uses thread pools. It also uses sign…
I don't think that a load of 172 is a good idea. I know this is a benchmark that is measuring how fast you can go ideally but in production the question is how fast you can go with with keeping the latency within the SLA. As a general rule you want to run your boxes around 1 normalized load ( load / # of CPU cores). The rest of the article is pretty nice.
Remember that processes in (D)isk Wait state count towards the load average even though they are not running or runnable.
Earlier quoted context omitted.
Having load average exceed core count isn't necessarily a sign of an imminent cascade failure. IIRC it's just a count of the number of processes that could run, but are waiting for a timeslice. A particular server and application might be perfectly fine with a load average that is 10 times the number of cores, as long as the average remains stable and the server is meeting response requirements.
Actually since you have no idea about what is causing the load (it can be wait on network IO) this is why I think that running your production system in that shape is not recommended. Out of curiosity in what situation is it ok to have significantly more things waiting to be running than your actual capacity? Seems like a bad capacity planning to me. Anyways, this is how it was done (keeping the normalized load aroun…
Hardly exciting stuff, async libraries have been doing this for things like DNS queries (where there's no portable non-blocking API) for decades. Good for Nginx addon devs I guess.
Earlier quoted context omitted.
Remember that processes in (D)isk Wait state count towards the load average even though they are not running or runnable.
As well as network IO. This is why just by the load you can't tell what is going on and this is exactly the reason why I don't like it too much in production. A box should do a have a smooth 15minutes normalized load over time. (If your workload changes you can do autoscaling, I think we used the normalized load as the metric for scaling up and down).