On Saturday 14 January 2006 19:13, Henrik Nordstrom wrote: > On Sat, 14 Jan 2006, H wrote: > > i don't know since the assertion failure ocurres independent of q1/q2 > > values > > Not the assertion in the subject. It's only if there is too many scheduled > diskd I/O requests at the same time, and these are limited by the q1/q2 > values. > > > after some time this function returns a bad buf value but why? > > The assertion says there is no I/O buffers left of the 96 statically > allocated buffers per diskd. > let's see if I understand what you say here, you say that if either q1 or q2 is set to a high enough value to use all 96 buffers the assertion failes and otherwise the msgs ar hold when reaching the q1 or q2 value and assertion do not fail? anyway I am surprised by your answer certainly the received error msg do not say that in any way probably you know that it means that so the surprise is that you let us crisscrossing options for two month until coming over with this wisdome even so, I mean even if the error msg really is saying what you tell us here I can not accept that squid ***crashes*** then for that and empties the cache dirs then If this error really means no buffers left then diskd processess should crash also and ever when the msgs are busy - but in this case squid gets it right and fails only for this particular transaction and can go on with diskIO soon the msgqueues are free Makes no sense to me that for buffers beeing out the diskspace count goes wrong but if so it is really necessary to check and repair this particular thing and for me this is a very serious bug since this happens independent of usage, means it happens on low traffic (<1000Kbit/s) and heavier (2-4MB/s) and also on heavy servers with 15-20MB/s after a certain time and not under a certain charge I like to discard "buffer out" - for me here is a leak somewhere which cause the problem, temporary buffer out I can no state on my system when monitoring this particular event. Obvious I should have more request on a heavy server so the problem should happen here more but it does not. So if your answer is it then I should get some relevant numbers with ipcs -o|a but the system is clear. Or is there something else? -- H. A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br