Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: Нагрузка на FreeBSD
> Ну что могу сказать, крутится vBulletin и форум очень посещаемый (в
> пиках 700 уникальных в течении 15 мин.), на линкусе, где он до этого
> стоял (2xXeon 5130, 4Gb, RAID5) нагрузка не превышала в пиках 25%
> процессора. Тут, на новом сервере FreeBSD 6.2 (Pentium D 940, 2
> ядра, 2GB) и такие жуткие перегрузки.
> Я не столь опытен во FreeBSD, что бы знать все подводные камни, но
> зная, что в рассылке есть люди, сильные в этой ОС, решил просить
> помощи. FreeBSD на новом сервере не по своей воле выбрал, потому
> теперь только бороться осталось...
> Не пойму, как на линкусе php и БД не давали такой страшной нагрузки, а тут
> дают?
1. У вас стало в два раза меньше RAM.
2. У линукса подсистема ввода/вывода имеет более хорошую логику
кэширования часто запрашиваемой информации. Так что у вас фактически была
двойная буфферизация данных БД - одна на ключах/буфферах MySQL, другая на
уровне OS.
Это так же помогало при записях/обновлениях БД.
3. Gentoo обычно всегда означает nptl, который никак не сравнится с pthreads.
4. RAID5 - а на новой машине?
Мощность процессора возможно реализовать на 90-100% /только/ при
условии кода близкого к идеальному и/или быстрого RAIDа и/или оптимальных
запросов к БД.
У вас же проблема налицо - MySQL, являсь самым последним звеном в
"логической" цепочке обработка запросов, банально и безбожно
тормозит.
nginx
apache
php
mysql
i/o
Посмотрите на mytop - запросов много? как долго они выполняются? Для
самых медленных из них проведите EXPLAIN и посмотрите хорошо ли они
индексированы. Если да - и запрос всё равно выполняется долго, то вам
вероятно надо увеличить key_buffer_size или innodb_buffer_pool_size,
в зависимости от того что вы используете.
Если у вас MyISAM, то почаще оптимизируйте таблицы.
Посмотрите на загрузку дисков - если они постоянно на отметке 100% -
то вот ваш bottleneck - постарайтесь каким-то образом эту нагрузку
снизить.. Из-за него страдает не только отдача статики, но и очень
сильно MySQL.
Уберите noatime с параметров mountирования партиции, настройте
буффера в nginx, руководствуясь error_log *log_path* debug; чтобы он не
писал временные файлы на диск если размер/количество буфферов не
достаточен(..чно).
В крайнем случае поразмыслите над запихиванием всего кода фрума на
ramdisk.
Понаблюдайте за статусами ngix (stub_status on) и Апачевским
/server-status на предмет открытых соединений и их количества,
сделайте выводы.
Протрассируйте все этапы выполнения запроса на
какую-либо страницу и найдите где этот запрос стопорится на самое
длительное время.
Полазте по системным логам (ошибки нехватки
памяти/буфуров/сокетов/слотов, неверных прав на файлы), почитайте dmesg,
потыкайте в sysctl - может вы просто попали в какой-то глупый лимит ресурсов.
Подходите к проблеме креативно. Не описывать же сейчас
пол-интернета статей по оптимизации серверов, причём сразу всех :)
--
Best regards,
Yuri Kushinov mailto:yuri.kushinov@xxxxxxxxx
|