14 messages in ru.sysoev.nginxRe: Feature requestED: monitoring Ngi...| From | Sent On | Attachments |
|---|---|---|
| François Battail | Apr 30, 2008 12:29 pm | |
| Manlio Perillo | Apr 30, 2008 1:16 pm | |
| François Battail | Apr 30, 2008 1:39 pm | |
| Manlio Perillo | May 1, 2008 1:30 am | |
| François Battail | May 1, 2008 1:58 am | |
| Manlio Perillo | May 1, 2008 2:39 am | |
| François Battail | May 1, 2008 5:42 am | |
| Rt Ibmer | May 1, 2008 9:59 am | |
| Grzegorz Nosek | May 1, 2008 11:35 am | |
| Manlio Perillo | May 1, 2008 11:57 am | |
| François Battail | May 1, 2008 1:25 pm | |
| Manlio Perillo | May 2, 2008 1:52 am | |
| François Battail | May 2, 2008 6:50 am | |
| Rt Ibmer | May 2, 2008 10:31 am |
| Subject: | Re: Feature requestED: monitoring Nginx from the outside | |
|---|---|---|
| From: | Manlio Perillo (manl...@public.gmane.org) | |
| Date: | May 1, 2008 11:57:50 am | |
| List: | ru.sysoev.nginx | |
Grzegorz Nosek ha scritto:
On Thu, May 01, 2008 at 11:39:50AM +0200, Manlio Perillo wrote:
Each variable will be correct, but since you are writing the value to a shared memory location not atomically, the variable as read by the client will not be correct.
Why? Reading several variables at once will not be atomic (unless protected by a lock) but individual reads will, as long as the variables in shm will fit into a sig_atomic_t each (e.g. 4 bytes on x86).
It can happen that when the client is reading the shared memory, Nginx concurrently writes this memory.
The problem is not with with Nginx, but with the client that will read the variables formatted in the shared memory.
The monitoring module for Nginx will write to the file this data, as an example (the numbers are in string format): accept:00000002 read:000000001 write:000000001 wait:000000001 mybackendserver1status:00000000 mybackendserver2status:00000001
The worst you can expect is that e.g. "requests ok" + "requests failed" won't be equal to "total requests". A sig_atomic_t is effectively atomic on most architectures (don't know whether POSIX guarantees it everywhere).
Moreover it really does not make sense to write in a shared memory if you want to support monitoring tools!
Just write a module like the stub_status module!
... which has to get its data from somewhere so it's going to face essentially the same problem.
No. With an HTTP interface the client will just make a request to obtain the data.
With shared memory it is a mess, I can't see any good reason to prefer this solution.
Finally there is one last problem. Nginx uses only a few shared variables (the one handled the the stub_status module).
All other variables are private to each worker process. This means that probably your shared memory location will contain values not very useful.
You could always add more information to a shared segment (like upstream_fair does).
Yes, but this means to change in a not trivial way the existing code in Nginx.
Best regards, Grzegorz Nosek
Regards Manlio Perillo