Все логично и супер, но работы на 2 недели. Быстрее Linux поставить :))))<br><br><div><span class="gmail_quote">2007/1/13, Yuri Kushinov <<a href="mailto:yuri.kushinov@gmail.com">yuri.kushinov@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Ну что могу сказать, крутится vBulletin и форум очень посещаемый (в<br>> пиках 700 уникальных в течении 15 мин.), на линкусе, где он до этого<br>> стоял (2xXeon 5130, 4Gb, RAID5) нагрузка не превышала в пиках 25%
<br>> процессора. Тут, на новом сервере FreeBSD 6.2 (Pentium D 940, 2<br>> ядра, 2GB) и такие жуткие перегрузки.<br>> Я не столь опытен во FreeBSD, что бы знать все подводные камни, но<br>> зная, что в рассылке есть люди, сильные в этой ОС, решил просить
<br>> помощи. FreeBSD на новом сервере не по своей воле выбрал, потому<br>> теперь только бороться осталось...<br>> Не пойму, как на линкусе php и БД не давали такой страшной нагрузки, а тут дают?<br><br><br> 1. У вас стало в два раза меньше RAM.
<br> 2. У линукса подсистема ввода/вывода имеет более хорошую логику<br> кэширования часто запрашиваемой информации. Так что у вас фактически была<br> двойная буфферизация данных БД - одна на ключах/буфферах MySQL, другая на уровне OS.
<br> Это так же помогало при записях/обновлениях БД.<br> 3. Gentoo обычно всегда означает nptl, который никак не сравнится с pthreads.<br> 4. RAID5 - а на новой машине?<br><br> Мощность процессора возможно реализовать на 90-100% /только/ при
<br> условии кода близкого к идеальному и/или быстрого RAIDа и/или оптимальных<br> запросов к БД.<br><br> У вас же проблема налицо - MySQL, являсь самым последним звеном в<br> "логической" цепочке обработка запросов, банально и безбожно
<br> тормозит.<br><br> nginx<br> apache<br> php<br> mysql<br> i/o<br><br> Посмотрите на mytop - запросов много? как долго они выполняются? Для<br> самых медленных из них проведите EXPLAIN и посмотрите хорошо ли они
<br> индексированы. Если да - и запрос всё равно выполняется долго, то вам<br> вероятно надо увеличить key_buffer_size или innodb_buffer_pool_size,<br> в зависимости от того что вы используете.<br> Если у вас MyISAM, то почаще оптимизируйте таблицы.
<br><br> Посмотрите на загрузку дисков - если они постоянно на отметке 100% -<br> то вот ваш bottleneck - постарайтесь каким-то образом эту нагрузку<br> снизить.. Из-за него страдает не только отдача статики, но и очень<br>
сильно MySQL.<br> Уберите noatime с параметров mountирования партиции, настройте<br> буффера в nginx, руководствуясь error_log *log_path* debug; чтобы он не<br> писал временные файлы на диск если размер/количество буфферов не
<br> достаточен(..чно).<br> В крайнем случае поразмыслите над запихиванием всего кода фрума на<br> ramdisk.<br><br> Понаблюдайте за статусами ngix (stub_status on) и Апачевским<br> /server-status на предмет открытых соединений и их количества,
<br> сделайте выводы.<br> Протрассируйте все этапы выполнения запроса на<br> какую-либо страницу и найдите где этот запрос стопорится на самое<br> длительное время.<br><br> Полазте по системным логам (ошибки нехватки<br> памяти/буфуров/сокетов/слотов, неверных прав на файлы), почитайте dmesg,
<br> потыкайте в sysctl - может вы просто попали в какой-то глупый лимит ресурсов.<br><br> Подходите к проблеме креативно. Не описывать же сейчас<br> пол-интернета статей по оптимизации серверов, причём сразу всех :)<br><br>
--<br>Best regards,<br> Yuri Kushinov mailto:<a href="mailto:yuri.kushinov@gmail.com">yuri.kushinov@gmail.com</a><br><br><br></blockquote></div><br>