Re: Re: Нагрузка на FreeBSD

Igor Sysoev is at rambler-co.ru
Sun Jan 14 19:06:41 MSK 2007


On Sun, 14 Jan 2007, Igor Sysoev wrote:

> On Sun, 14 Jan 2007, [UTF-8] Дмитрий Леоненко wrote:
>
>> Ну память само собой отличается... в одном месте FB-DIMM 667MHz, в новом
>> DDRII-400
>> 
>> Да не вопрос это, что сервера в железе отличаются... вопрос в том, что
>> нагрузка становится настолько нереальной, что порой даже команды ввести
>> нельзя.
>> 
>> Все таки на новый сервер скорее всего станет линкус, только пока вопро,
>> какой...
>> В идеале (для меня) станет Gentoo, если не будет такой возможности - станет
>> CentOS  последняя.
>> Вот тогда я поставлю ТОЧНО такие же конфиги, и мы поговорим о мифах и
>> реальности. Я больше чем уверен, что разница будет  очень убедительной...
>
> Я не знаю, насколько FB-DIMM 667MHz, чем DDRII-400. Возможно, и не быстрее -
> сейчас 667 не обязательно быстрее 400, хотя склоняюсь к тому, что
> всё же быстрее.
>
> Как-то давно я столкнулся с ситуацией, когда два процессора оказались лучше,
> чем один. У Интела были такие сервера, в которых во время загрузки BIOS
> мог потерять второй процессор, и OS его тоже не видела. Для того, чтобы
> процессор появился снова, нужно было зайти в BIOS, сказать retest CPU и
> перегрузиться. Дело было на FreeBSD 4.x, ядро которой к SMP приспособлено
> по минимуму - если одни процессор зашёл в ядро, то второй при заходе в
> ядро будет просто крутиться в spinlock'е, пока первый процессор из ядра
> не выйдет. То есть, если процессы делают много сисколов, то велика
> вероятность того, что процессоры будут часто бессмысленно крутиться
> в спинолоках, ожидая друг друга. Если же процессы в ядро заходят
> редко, то добавление второго процессора действительно увеличивает
> производительность (но не на 100%, а на 80-95% в зависимости от характера
> работы). Так вот, Апач с mod_accel/mod_deflate/SSI, вопреки моим ожиданиям,
> выигрывал от второго процессора, потому что, когда один раз после
> перезагрузки машина загрузилась без второго процессора, загрузка на ней
> выросла до 100% и процессора явно не хватало - всё работало медленно.
>
> Возвращаясь к исходной ситуации, что мы видим:
>
> 1) cудя по top'у, процессы в ядро ходят редко 95% user:
>
> CPU states: 95.1% user,  0.0% nice,  4.1% system,  0.7% interrupt, 0.0% idle
>
> стало быть, налицо нагрузка, которая выигрывает от числа процессоров
> даже на OS с примитивной поддержкой SMP (хотя FreeBSD 6.x к таким не
> относится). От mysql и особенно от php тикой характер работы вполне ожидаем.
>
> 2) новая система имеет в 2 раза меньше CPU cores и в 2 раза меньше кэша,
> а размер кэша для современных процессоров весьма критичен (критичнее,
> например, чем частота) и, возможно, более медленную память.

Почитал я про 2 DIMM'а DDR2-400 vs 4 DIMM'а FB-DIMM-667 и сдаётся мне,
что новая система с учётом разницы cores/кэша/памяти раза в 4-8 медленее,
чем старая для данного типа нагрузки.
Так что нет ничего удивительного в 100% vs 25%.

> Резюме такое - я сильно сомневаюсь, что Линукс на этом же железе
> покажет существенно лучшие результаты - тут от OS мало что зависит.
>
>> 14.01.07, Igor Sysoev <is at rambler-co.ru> написал(а):
>>> 
>>> On Sun, 14 Jan 2007, Igor Sysoev wrote:
>>> 
>>> > On Sat, 13 Jan 2007, [UTF-8] Дмитрий Леоненко wrote:
>>> >
>>> >> Ну что могу сказать, крутится vBulletin и форум очень посещаемый (в
>>> пиках
>>> >> 700 уникальных в течении 15 мин.), на линкусе, где он до этого стоял
>>> >> (2xXeon
>>> >> 5130, 4Gb, RAID5) нагрузка не превышала в пиках 25% процессора. Тут, на
>>> >> новом сервере FreeBSD 6.2 (Pentium D 940, 2 ядра, 2GB) и такие жуткие
>>> >> перегрузки.
>>> >
>>> > Я правильно понимаю,
>>> 
>>> И похоже, у них ещё и скорость шины отличается в 1.6 раза:
>>> 
>>> > что было два Xeon 5130 2GHz, каждый из которых dual core и имеет кэш 4M,
>>> 
>>> 1333MHz
>>> 
>>> > а стало один Pentium D 940 3GHz, который dual core и тоже имеет кэш 4M ?
>>> 
>>> 800MHz
>>> 
>>> Возможно, в системах ещё и память отличается по скорости.
>
>
> Игорь Сысоев
> http://sysoev.ru
>
>
>

Игорь Сысоев
http://sysoev.ru





More information about the nginx-ru mailing list