> Ну что могу сказать, крутится 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 - может вы просто попали в какой-то глупый лимит ресурсов.
Подходите к проблеме креативно. Не описывать же сейчас пол-интернета статей по оптимизации серверов, причём сразу всех :)
