Что означает B --PR-- в выводе onstat'а?
Особенно когда таких довольно много (полтора-два десятка)?

Ну, то есть, чего именно он ждет и почему такое происходит?

vasilisЕвгений, вы же старый и корректный посетитель форума - неужели и вы считаете, что версия сервера и подробное описание ситуации не важны ?Спасибо за комплименты :)) Если честно - я совершенно не подумал о том, что именно для этого вопроса актуальна версия сервера. 9.40.FC7.
vasilisМожет быть несколько причин, в том числе и ожидание свободного буфера для записи считанных страниц с диска при интенсивном сканировании (таблицы или индекса). Может у вас BT-scanner интенсивно работает...Вот примерно в таком духе я и ожидал ответа. Спасибо, буду думать. Я же не админ, мне иногда многие вещи бывают в новинку :)
vasilisМожно добавить буферов, можно увеличить количество LRUS (т.к. при использовании буфера в цепочке блокируется она вся), можно уменьшить сканирование таблиц...
Возможно, что ожидается буфер, просто занятый другим интенсивным процессом (идет вставка или апдейт), но обычно это актуально только для одной нити, а не для многих.
Посмотри примеры
http://www.iiug.org/forums/ids/index.cgi/noframes/read/400
http://www.webservertalk.com/archive221-2006-2-1387239.html

zaietsНу а если разработчик - смотрите сразу запросы.Ну, вроде того. Беда только в том, что у меня этих запросов - как у дурака фантиков :))
zaietsЕсть вероятность, что запросы неоптимальны и используют много дискового чтения.Это даже не вероятность, это 100%-ный факт.

Журавлев ДенисЕсли запрос выполняется полсекунды -- все труба, на боевом это будет мешать.Денис, Вы большой оптимист
Я к тому что у меня тут есть запросы которые не то что полсекунды - за полчаса не управляются