LINUX.ORG.RU
← Dr.Web LiveCD
David Xu уходит из FreeBSD →
 ← 1 2 3

Интересно, какая версия ядра в этом SLES 9 SP3? что-то похоже на 2.6.5, если судить по release notes (старье).

kmike ★★
()

Ну че сказать, пых-пых-бе-бе это как раз то, для чего надо покупать 8-процессорный сервер.

Sun-ch ☆
()

Комментарии автора статьи: "Со фрей я до сих пор уверен, что чего-то там недонастроили, хотя попыток была масса заставить ее работать." Похоже на то. =)

anonymous
()
Ответ на: комментарий от Sun-ch

>Ну че сказать, пых-пых-бе-бе это как раз то, для чего надо покупать 8-процессорный сервер.

А что, скажем (ну, от балды :D ) Java уже не использует threads? :)

...

Кстати, вопрос такой офтопичный - Erlang под Linux использует системные threads или что-то своё?

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

> в общем фряха обделалась по полной... что и ожидалось

Кстати, я б особенно не радовался и обратил бы внимание, что по сути тестировалось две Enterprise-системы и одна свободная.

anonymous
()
Ответ на: комментарий от anonymous

> Кстати, я б особенно не радовался и обратил бы внимание, что по сути > тестировалось две Enterprise-системы и одна свободная.

Ну дык предложи Enterprise-систему на основе BSD :)

Korwin ★★★
()
Ответ на: комментарий от KRoN73

>Кстати, вопрос такой офтопичный - Erlang под Linux использует системные threads или что-то своё?

Афаик, свое. Думаю, Linux бы помер от такого количества нативных тредов :)

AsphyX ★★★
()
Ответ на: комментарий от KRoN73

Более грамотно было вынести мускуль как отдельный сервис, поскольку тюних мускуля и апача может быть ортогонален.
Все это сильно смахивает на пеар того что в Трините есть такие мегасундуки с 4 оптеронами. Интереснее посмотреть эти тесты в сравнении с ниагарой от сан, не только абсолютные замеры призводительности, но и то в какие деньги это обойдется, в том числе содержать такого монстра на площадке.

Sun-ch ☆
()
Ответ на: комментарий от kmike 

>Вообще работа проделана гигантская, спасибо! 

Спасибо, на тесты ушло около трех недель, не постоянно конечно, но в чистую примерно рабочая неделя, 90% времени на фрю :) Потом пару дней на обработку результатов. Три дня на публикацию :)

Вот статистика системы с FreeBSD:

root at bsd# vmstat 5 99999
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr da0 pa0   in   sy  cs us sy id
57 7 0 1437664 14685816 15880   0   1   0 15602   0   0   0  751 32946 4527 21  6 73
34 0 0 1414596 14709272 42496   0   0   0 44131   0  17   0 2234 107315 10897 60 15 25
25 18 3 1448772 14681704 45861   0   0   0 44197   0  51   0 2430 128607 14323 59 17 24
115 0 0 1475388 14667744 41516   0   0   0 41086   0  26   0 1893 99250 12311 55 18 27
48 10 2 1468312 14668900 44786   0   0   0 45002   0  21   0 2281 114561 14933 61 15 24
52 0 1 1465544 14663376 36861   0   0   0 36952   0  28   0 2139 106886 13897 51 16 33
40 1 4 1493980 14645444 46600   0   0   0 46322   0  16   0 1986 118531 12362 62 17 22
 9 62 0 1433988 14680880 42577   0   0   0 44164   0  26   0 2516 112201 14278 58 15 27
29 22 3 1427156 14686252 41844   0   0   0 42137   0 114   0 2650 100774 12208 53 20 27
61 5 0 1454092 14660264 33276   0   0   0 32187   0 171   0 2345 95594 12969 44 13 43
72 0 0 1464848 14652860 43017   0   0   0 42969   0  13   0 1958 92878 10794 55 20 25
26 14 0 1439668 14668572 47654   0   0   0 48545   0  22   0 2164 122032 12913 60 17 23
60 1 1 1447260 14661812 48921   0   0   0 48618   0   6   0 2308 131291 15413 61 16 23
44 0 0 1464040 14647920 43565   0   0   0 43346   0  25   0 1974 102238 14174 52 17 30
29 1 0 1478040 14641844 48709   0   0   0 48523   0  17   0 2200 108484 10805 61 15 23
51 20 0 1444064 14656948 39772   0   0   0 40836   0  21   0 2223 105965 11112 57 19 23
46 0 0 1448308 14654368 45678   0   0   0 45765   0  13   0 2142 102726 12209 58 15 27
39 9 0 1450852 14646816 45919   0   0   0 46260   0  15   0 2018 113011 12957 59 14 26
89 1 1 1452640 14634792 36423   0   0   0 35692   0  17   0 1987 110922 12942 55 20 24
63 4 0 1442528 14649108 41640   0   0   0 41725   0  17   0 2358 116923 13326 61 14 25
43 0 0 1445940 14647980 47792   0   0   0 48728   0  17   0 2294 113538 13155 59 16 25
50 3 4 1492220 14606172 33088   0   0   0 31201   0  15   0 1771 108095 18050 59 18 23
59 0 1 1437268 14649388 46433   0   0   0 48720   0  16   0 2652 133756 15102 61 16 24
19 2 8 1421944 14656080 40356   0   0   0 40212   0  10   0 1982 113308 15619 61 18 22

root at bsd# top -b -i -s 5 -b -n 50
last pid:   860;  load averages: 60.55, 38.98, 20.33  up 0+00:15:38    20:07:14
295 processes: 62 running, 233 sleeping

Mem: 823M Active, 56M Inact, 288M Wired, 812K Cache, 214M Buf, 14G Free
Swap: 3991M Total, 3991M Free


  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
  827 mysql     112  20    0   351M   131M kserel 0   8:00 30.13% mysqld
  668 nobody      1   4    0 32540K  7928K sbwait 6   0:13  0.73% httpd
  625 nobody      1  79    0 33748K  9148K CPU6   7   0:12  0.73% httpd
  666 nobody      1  77    0 32640K  8028K RUN    5   0:12  0.73% httpd
  655 nobody      1   4    0 33372K  8760K sbwait 4   0:12  0.73% httpd
  619 nobody      1   4    0 36348K 10468K sbwait 7   0:12  0.73% httpd
  719 nobody      1   4    0 36152K 10272K sbwait 1   0:11  0.73% httpd
  687 nobody      1   4    0 35736K  9856K sbwait 2   0:11  0.73% httpd
  728 nobody      1   4    0 35580K  9692K sbwait 2   0:11  0.73% httpd
  582 nobody      1  -4    0 36368K 10488K RUN    5   0:11  0.73% httpd
  710 nobody      1  -4    0 35532K  9644K RUN    5   0:15  0.00% httpd
  718 nobody      1   4    0 35484K  9608K sbwait 0   0:14  0.00% httpd
  607 nobody      1  -4    0 35788K  9904K RUN    5   0:14  0.00% httpd
  610 nobody      1  -4    0 35768K  9888K RUN    5   0:14  0.00% httpd
  620 nobody      1   4    0 35488K  9600K sbwait 5   0:14  0.00% httpd
  673 nobody      1  -4    0 32800K  8188K RUN    5   0:13  0.00% httpd
  709 nobody      1   4    0 35576K  9688K sbwait 6   0:13  0.00% httpd
  652 nobody      1   4    0 33432K  8820K sbwait 3   0:13  0.00% httpd
  638 nobody      1   4    0 32976K  8372K sbwait 2   0:13  0.00% httpd
  616 nobody      1  -4    0 32536K  7932K RUN    5   0:13  0.00% httpd
  591 nobody      1  -4    0 33304K  8512K RUN    5   0:13  0.00% httpd
  658 nobody      1   4    0 35504K  9628K sbwait 7   0:13  0.00% httpd
  589 nobody      1  77    0 35516K  9640K RUN    2   0:13  0.00% httpd
  686 nobody      1   4    0 33288K  8684K sbwait 2   0:13  0.00% httpd
  617 nobody      1   4    0 33480K  8696K sbwait 6   0:13  0.00% httpd
  612 nobody      1   4    0 36212K 10344K sbwait 4   0:13  0.00% httpd
  596 nobody      1   4    0 33432K  8816K sbwait 2   0:13  0.00% httpd
  593 nobody      1   4    0 36460K 10580K sbwait 0   0:13  0.00% httpd
  720 nobody      1  -4    0 36448K 10564K RUN    5   0:13  0.00% httpd
  724 nobody      1   4    0 35768K  9892K sbwait 2   0:13  0.00% httpd
  676 nobody      1  77    0 35748K  9868K RUN    0   0:13  0.00% httpd
  688 nobody      1   4    0 35604K  9720K sbwait 2   0:13  0.00% httpd
  665 nobody      1   4    0 33320K  8528K sbwait 5   0:13  0.00% httpd
  670 nobody      1  -4    0 35576K  9700K RUN    5   0:13  0.00% httpd
  650 nobody      1  -4    0 33480K  8688K RUN    5   0:13  0.00% httpd
  600 nobody      1   4    0 35836K  9956K sbwait 6   0:13  0.00% httpd
  662 nobody      1  -4    0 33140K  8532K RUN    2   0:13  0.00% httpd
  583 nobody      1  -4    0 35760K  9880K RUN    5   0:13  0.00% httpd
  590 nobody      1   4    0 35600K  9724K sbwait 2   0:13  0.00% httpd
  706 nobody      1   4    0 32440K  7832K sbwait 6   0:13  0.00% httpd
  643 nobody      1  -4    0 33252K  8640K RUN    5   0:12  0.00% httpd
  622 nobody      1   4    0 35548K  9660K sbwait 0   0:12  0.00% httpd
  641 nobody      1  78    0 32704K  8068K CPU3   5   0:12  0.00% httpd
  621 nobody      1   4    0 32432K  7820K sbwait 6   0:12  0.00% httpd
  671 nobody      1   4    0 32604K  7992K sbwait 7   0:12  0.00% httpd
  672 nobody      1   4    0 36064K 10180K sbwait 6   0:12  0.00% httpd
  704 nobody      1   4    0 36400K 10524K sbwait 2   0:12  0.00% httpd
  680 nobody      1  -4    0 33344K  8560K RUN    5   0:12  0.00% httpd
  627 nobody      1   4    0 32604K  8000K sbwait 6   0:12  0.00% httpd
  729 nobody      1   4    0 33172K  8556K sbwait 7   0:12  0.00% httpd

shkoda
() автор топика
Ответ на: комментарий от Sun-ch

>Более грамотно было вынести мускуль как отдельный сервис, поскольку тюних мускуля и апача может быть ортогонален

Пробовал, погрешность в пределах измерений. Нагрузка на мускул ничтожна по сравнению с остальным.

> Все это сильно смахивает на пеар того что в Трините есть такие мегасундуки с 4 оптеронами.

Только ленивый их сейчас не толкает, так что пеар в планах не стоял.

> Интереснее посмотреть эти тесты в сравнении с ниагарой от сан

Не поверишь, этим и занимаюсь сейчас, правда ниагара дохленькая :) Кто даст нормальную ниагару? Нужна на пару дней, для аналогичных тестов.

shkoda
() автор топика
Ответ на: комментарий от kmike

>Интересно, какая версия ядра в этом SLES 9 SP3? что-то похоже на 2.6.5, если судить по release notes (старье).

Совершенно согласен. Посвежее ядро никак ?

robot12 ★★★★★
()
Ответ на: комментарий от shkoda

> Не поверишь, этим и занимаюсь сейчас, правда ниагара дохленькая :) Кто даст нормальную ниагару? Нужна на пару дней, для аналогичных тестов.

Кстати, большое спасибо за работу. И еще бОльшее - за публикацию результатов. =)

anonymous
()
Ответ на: комментарий от anonymous

> фряха обделалась по полной
"при большом наплыве пользователей его (Solaris) поведение предпочтительнее" - что так же ожидалось

anonymous
()
Ответ на: комментарий от anonymous

Давно известно что больше всего грузит систему mysql

ntimmy ★
()
Ответ на: комментарий от anonymous

Та же ерунда. :( root@student8:/ # nslookup ya.ru Server: 192.168.1.253 Address: 192.168.1.253#53

Non-authoritative answer: Name: ya.ru Address: 213.180.204.8

root@student8:/ # nslookup trinity.su ;; connection timed out; no servers could be reached

anonymous
()
Ответ на: комментарий от shkoda

> Я не думаю что кардинально результаты поменяются.

C Linux нельзя такого утверждать, при нынешней системе разработки :)

Casus ★★★★★
()
Ответ на: комментарий от anonymous

У меня ложится на питерстаре:

traceroute to 81.3.165.126 (81.3.165.126), 30 hops max, 40 byte packets 1 213.59.0.129 (213.59.0.129) 0.845 ms 0.576 ms 0.813 ms 2 msk-scr2-ge3-2.rt-comm.ru (217.106.0.65) 12.554 ms 12.807 ms * 3 * * * 4 msk-bbn1-ge7-1.rt-comm.ru (217.106.0.46) 12.808 ms 12.465 ms 12.495 ms 5 spb-bbn0-po8-3.rt-comm.ru (217.106.7.133) 12.945 ms 21.033 ms 12.759 ms 6 spb-dsr2-ge0-0-0-0.rt-comm.ru (217.106.0.162) 12.505 ms 12.313 ms 12.402 ms 7 195.161.4.34 (195.161.4.34) 12.967 ms 13.073 ms 12.906 ms 8 J7-1-K4.ge-0-3-0-7.peterstar.net (84.204.188.6) 13.012 ms 13.396 ms 13.220 ms 9 J10-1-321.ge-0-1-0-55.ip.peterstar.net (84.204.190.6) 13.152 ms !N 13.319 ms !N 13.116 ms !N

shkoda
() автор топика

Есть вероятность что linux слил при большой нагрузке из-за того что использовалось старое ядро ?

anonymous
()

А где w2k3 ?

anonymous
()
Ответ на: комментарий от shkoda

Я не знаю на чем у меня, я за проксей. Но нахожусь в питере.

anonymous
()
Ответ на: комментарий от shkoda

MinSpareServers 200 MaxSpareServers 500 StartServers 200 MaxClients 150 крутой конфиг

darkden ★
()

Хм, если во фре проц не нагрузили, значит явно что-то не недокрутили. В tcp/ip стеке сильно ковырялись? Какой-нибудь delayed ack?

anonymous
()
Ответ на: комментарий от shkoda

> FreeBSD:

Результаты, по-моему, могли бы быть на FreeBSD лучше, если в конфигурации ядра закомментировать строку

makeoptions DEBUG=-g

И поменять планировщик с 4BSD на ULE (2 следующие строки в конфигурационном файле ядра).

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

> И поменять планировщик с 4BSD на ULE

"Перекомпиляция ядра с ULE планировщиком никакого результата не дала." Внимательнее читаем, внимательнее. =)

anonymous
()
Ответ на: комментарий от Sorcerer

И были бы еще лучше, если покрутить somaxconn, delayed_ack...

И правильно собрать MySql, потом не забыть ему libthr.

baka-kun ★★★★★
()
Ответ на: комментарий от shkoda

под фрёй: . похоже что где-то облажались с настройкой mysql. Ерунда какая-то получается. . если ещё не убили покажите `systat -vm` и `mount` . accf_http загрузить не забыли?

ignik
()
Ответ на: комментарий от Sorcerer

> Результаты, по-моему, могли бы быть на FreeBSD лучше, если в конфигурации ядра закомментировать строку

Не похоже. Судя по всему где-то пропущена какая-то дурь при настройке фри. imho было бы не грех приложить конфиги (хотя бы sysctl -a), показать что в make.conf etc. Хотя бы рассказать как mysql собирали...

ignik
()

под линуксом надо было попробовать разные планировщики (коих в ядре 2.6 - 4 штуки)

те, что работают хорошо при средной нагрузке, могут загибаться при сильной и наоборот

плюс для этого сервера нужно ядро собранное с поддержкой NUMA

зы про наличие NUMA во фре - ни чего не знаю

vadiml ★★★★★
()

Что нужно было сделать для FreeBSD:

1. Убрать makeoptions DEBUG=-g из конфига ядра.
2. Добавить следующие строчки в /etc/make.conf и пересобрать софт:
CPUTYPE
CFLAFS= -O2 -pipe
COPTFLAGS= -O2 -pipe
3. Увеличить recvspace и sendspace до 65535
4. Есть вероятность, что апачу могло нехватить разделяемой памяти (shared memory) (по дефолту ее вроде всего 4 мб). Прописать осмысленные значения в
kern.ipc.shmall
kern.ipc.shmmax
kern.ipc.semmap

Есть возможность прогнать те же тесты с такой настройкой FreeBSD?

anonymous
()
Ответ на: комментарий от anonymous

> Что нужно было сделать для FreeBSD:

а в линуксе это уже _есть_ :)

freebsd хорошая, удобная и гибкая система, но по сравнению с линуксом тормознутая

JB ★★★★★
()
Ответ на: комментарий от JB

> а в линуксе это уже _есть_ :)

...в Enterprise-системе. =) Подозреваю, что неэнтерпрайз-линухи изначально сконфигурированы несколько иначе. =)

anonymous
()
Ответ на: комментарий от Sorcerer

> makeoptions DEBUG=-g Сорри, в тестах этого не было. Конфиги собирал в конце, а с фрей прыгали долго, в т.ч. и debug для этого включали.

shkoda
() автор топика
Ответ на: комментарий от anonymous

> 1. Убрать makeoptions DEBUG=-g из конфига ядра.

его не было там, это в процессе траблшутинга добавлялось :)

> 2. Добавить следующие строчки в /etc/make.conf и пересобрать софт: > CPUTYPE

а смысл? Фря там была AMD64

> CFLAFS= -O2 -pipe > COPTFLAGS= -O2 -pipe

> Есть возможность прогнать те же тесты с такой настройкой FreeBSD?

уже нет. Как тестилось написано, так что всё в ваших руках....

shkoda
() автор топика
Ответ на: комментарий от vadiml

> под линуксом надо было попробовать разные планировщики (коих в ядре 2.6 - 4 штуки)

... и в солярке 5, итого 9 итераций, тогда бы статьи вообще не было.

> те, что работают хорошо при средной нагрузке, могут загибаться при сильной и наоборот

и поставить в крон скриптик который в зависимости от текущей нагрузки будет менять переподгружать ядро?

shkoda
() автор топика
Ответ на: комментарий от anonymous

забыл добавить что надо еще ядро переписать :)
и фря все порвет.

fghj ★★★★★
()
Ответ на: комментарий от KRoN73

> Кстати, вопрос такой офтопичный - Erlang под Linux использует системные threads или что-то своё?

Легковесные процессы. Треды тоже умеет.

fernik ☆
()
Ответ на: комментарий от shkoda

Без обид, ребята, но по вашим высказываниям похоже, что вы очень хотели победы Соляриса, что не замедлило сказаться на результах :)

annoynimous ★★★★★
()
Ответ на: комментарий от anonymous

> Подозреваю, что неэнтерпрайз-линухи изначально сконфигурированы несколько иначе. =)

почти все современные дистрибутивы как раз так и собираются

JB ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3
← Dr.Web LiveCD
Open Source
David Xu уходит из FreeBSD →