а не должен. особенно быстро работает подключение через локальный unix-сокет.
какой длительности пауза? сколько всего подключений в секунду происходит?
Тут нечего крутить. Работает он так интенсивно. Только выдумывать как уменьшить число запросов и то не обязательно получится лучше.
а там разве рядом не написан совет Optimize queries and/or use InnoDB to reduce lock wait ?
madoff, разве не от мегабайт ?
к тому же, если боитесь переплатить, можно оплатить конкретный потолок типа лишь 10 мбит. ну нажмет пользователь лишний раз f5, не переломится.
Я помню недавно туда avito.ru переезжал. Трафика страшно представить сколько. Было много воплей у риелторов о неправильном срабатывании. Сейчас почему-то уехал.
Не так много, как apache. у ТС вообще общая интенсивность 6 мбайт/сек (в первом посте)
я вот даже логи статики иногда отключаю в nginx. Зачем они ? для анализа посещаемости не нужны все равно.---------- Добавлено в 23:08 ---------- Предыдущее сообщение было в 23:06 ----------fiper, лучше будет разобраться почему nginx так активно пишет. но для этого готовой команды у меня нет. "надо смотреть".
Не думаю. Статика же и так кеширутся ОС в памяти. Нет смысла копировать из одной памяти в другую память уменьшая тем самым доступную память.
а представь себе, достаточно скромно. но там же оплата по трафику. файлообменниками и прочим к ним даже не стоит соваться.
и веселые они. qrator некоторых ботов банит с нулевого раза.
а вот это глупо, если можно просто их не создавать.
и таки интересно услышать что скажет myhand, т.к. подобные проблемы напрямую подрывают концепцию отказа от прямой раздачи статики с помощью nginx как это сделано в ispmanager.
fiper, чего это у вас nginx так много на диск пишет? временные файлы ? а откуда они берутся если вы раздаете статику ?
это скорее не нормально.
можете попытаться с помощью iostat -x 10 понять насколько большую часть нагрузки на диск дает запись по сравнению с чтением.
Надо перевести. я имел ввиду стек внутри процесса. очевидно, у каждого потока свой собственный стек. или нет?
предложение "SIZE is the virtual size of the process (code+data+stack) " относится к виртуальному размеру. то есть SIZE не связано с тем, сколько страниц из этого запрошенного стека реально использованы.
насчет ps я, кажется, ошибся. тоже не знаю как этот стект посчитать из данных ps.
Вообще-то, да. Меньше чем apache в пересчете на одного клиента. Вопрос лишь в том насколько меньше.
Фигню скопипастил. Напиши да или нет.
Реально использованный стек можно посмотреть в /proc/<pid>/smap, но нигде не видно включает ли значение суммарное значение rss этот стек.
Вот у меня стек в апачах очень большой - по 70 мб на процесс. Скорее всего он не используется весь.
