LINUX.ORG.RU

Тесты масштабируемости Linux и BSD


0

0

Сравнение Linux 2.4, Linux 2.6, OpenBSD 3.4, FreeBSD 5.1 и NetBSD 1.6.1, в частности сетевых подсистем, управление процессами и памятью, операций с диском.
Результаты говорят сами за себя, но основной вывод: масштабируемость Linux 2.6 достойна похвалы!

>>> Подробности

anonymous

Проверено: maxcom

Ответ на: комментарий от R00T

Блин, только сейчас заметил: >I used my experimental web server gatling to measure these numbers. All the benchmark programs are also part of the gatling package.

То есть он не apache тестировал.

to R00T Попробуй его тесты You can download gatling via anonymous cvs from:

% cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co libowfat

% cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co gatling

libowfat contains my implementation of the IO API, gatling is the webserver. You need to build libowfat first. If you are using Linux, also check out

% cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co dietlibc

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

А вот ещё тесты ;)
После одного из местных флеймов на тему "журналы рулят, софтапдейты - АЦТОЙ", или "Линукс - RULEZZ, а BSD - R.I.P." - уже не помню ;-) решил проверить, так это или не так, чисто для себя. Написал простой бенч, погонял на своей машине, а сейчас вот решил выложить результаты и программу на http://benchfs.narod.ru , слегка причесав на скорую руку для солидности. :o)
Может кому пригодится...

Alex_M
()

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

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

man 4 syncer

default

kern.filedelay 30 time to delay syncing files
kern.dirdelay 29 time to delay syncing directories
kern.metadelay 28 time to delay syncing metadata

Менять не пробовал ?

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

>man 4 syncer

>default

>kern.filedelay 30 time to delay syncing files
>kern.dirdelay 29 time to delay syncing directories
>kern.metadelay 28 time to delay syncing metadata

>Менять не пробовал ?

Не пробовал. А смысл? Времена здесь очень большие, так, что на производительность эти изменеия врядли повлияют, пока не уменьшишь до ~1 сек, а затем она (производительность) резко упадёт, приближаясь к случаю отсутствия софтапдейтов. К тому же на реальной системе эти переменные sysctl редко трогают.
Или я не о том?

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

Ну а если писать не 50 тыс. файлов, а 2 млн., да в разные катологи,

думаю не даром их позволяют менять.

Sun-ch
()
Ответ на: чушь собачья! от Dselect

2Dselect (*) (20.10.2003 21:03:22)

>Человеку, утверждающему о превосходстве убожества KDE и глюкала GNOME над CDE, срочно необходима помощь психиатра.

Так обычно говорят те, кто CDE только на картинках видал Кааанешна, CDE - это круто, для тех, кто больше 15 минут в ней не работал

anonymous
()

Блин Пингвины опять радуются. В каждой OS есть свои прелести и минусы. Пингвин это не Unix.

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

>Блин Пингвины опять радуются. В каждой OS есть свои прелести и минусы. Пингвин это не Unix

Во бля, ещё один умник ...

Формально - FreeBSD тоже не UNIX ...

Поставь себе солярку и наслаждайся ...

anonymous
()
Ответ на: чушь собачья! от Dselect

>еловеку, утверждающему о превосходстве убожества KDE и глюкала GNOME >над CDE, срочно необходима помощь психиатра

Позвольте с Вами не согласиться. Я достаточно поработал в CDE и ... эта штука однозначно не для пользователя.

А на счет психиатра - это к SUN. Именно они собираются менять
CDE на GNOME. То, что они сейчас в ЖОПЕ - заслуга таках вот крикунов.
Слишком долго орали что мол CDE РУЛИТ, а M$ сосет, Sparc рулит - X86
сосет ... Доорались ... теперь у них и GNOME рулит и команду набрали
чтоб Slowaris на x86 оптимизировать. ( с чего бы кстати ? видно
херово они знают свой же Solaris ибо по утверждению многочисленных
крикунов он ведь впереди планеты всей! )

>что в Solaris есть RBAC и потенциальная угроза от такого рода дыр
>гораздо меньше, чем в случае [непропатченного RSBAC|grsec|... ] Linux,

Это частично справедливо только для Trusted Solaris. В обычной соляре
нельзя ограничить привелегии root'а, в получении коих и есть цель большинства атакеров.

Captain.

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

Ребята, а кто-нибудь знает, как измеряют загрузку процессора в виндах? А то что-то захотелось потестировать NTFS для полного комплекта ;)

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

Пуск/пан. управления/Админ./Системный монитор

Счетчики % загруженности процессора и далее, там увидишь

справа в окошке, на каком cpu мерять

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

Вообще-то можно и не тестировать... И так всё известно - очень медленная штука. Хотя для успокоения совести... :-)

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

2Alex_M: Вот тест для ext3 на примерно такой же машинке...

./benchfs /tmp/test
Target directoty is /tmp/test
Free: 38768640K. OK.
## Test 1. We will be writing 5000 files, 256 bytes each...
%user %sys %idle real,s Kb/s
6.22 88.60 5.18 1.93 647.67
## Test 2. We will be writing 50000 files, 256 bytes each...
%user %sys %idle real,s Kb/s
1.98 95.48 2.54 250.36 49.93
## Test 3. We will be writing one big file, 1500000 Kbytes of size...
%user %sys %idle real,s Kb/s
2.47 16.78 80.75 80.45 18645.12
## Test 4. We will be reading 50000 files, 256 bytes each...
%user %sys %idle real,s Kb/s
11.10 17.78 71.12 30.37 411.59
## Test 5. We will be reading the previously written big file...
%user %sys %idle real,s Kb/s
1.04 13.58 85.38 77.97 19238.17
## Test 6. We will be reading 50000 files, 256 bytes each in random order...
%user %sys %idle real,s Kb/s
0.77 10.40 88.83 337.86 37.00
## Test 7. Now we will be removing 50000 files, 256 bytes each...
%user %sys %idle real,s Kb/s
1.68 45.56 52.76 4.17 2997.60

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

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

>Вот тест для ext3 на примерно такой же машинке...
...

Памяти всё-таки немного побольше? Да и своп, наверно не отключил. Кэширование всё-таки даёт о себе знать.
А на счёт вывода: при записи 5000 файлов - 647.67Kb/s, 50000 - 49.93Kb/s. В 13 раз медленнее!
Не правда-ли, есть о чём подумать, учитывая, что на всех остальных ФС - падение - от силы процентов 20?

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

>А на 2 миллиона слабо зарядить :)
А чё, заряди :) Переменную n подправь и вперёд!
Тока боюсь, результата ждать устанешь ;)

>Пуск/пан. управления/Админ./Системный монитор
>Счетчики % загруженности процессора и далее, там увидишь

Я имел ввиду как это сделать через Win API? Через что ентот самый "Системный монитор" инфу берёт?

Alex_M
()

все эти - тесты дерьмо!
лучший тест - реальная жизнь.

вот вы супер-крутые БСДешники, обясните, как такая глючная, кривая поделка для красноглазых под названием ляликс может держать одновременно 200000 коннектов на серверах p2p в сети ed2k? ААА?

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

RE:

>Я имел ввиду как это сделать через Win API? Через что ентот самый "Системный монитор" инфу берёт?

В MSDN по performance monitoring API искать не пробовал? ;)

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

> очевидно никак, сокетов не хватит

У бзди не хватит. Ей конфиг править надо и перегружать, как винду какую.
В линуксе все дела можно на лету подстроить через /proc или /sys.

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

>У бзди не хватит. Ей конфиг править надо и перегружать, как винду какую. В линуксе все дела можно на лету подстроить через /proc или /sys.

В 5.x уже не надо перегружать.

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

>У бзди не хватит. Ей конфиг править надо и перегружать, как винду какую. В линуксе все дела можно на лету подстроить через /proc или /sys. В 5.x уже не надо перегружать.

И в 4-ке и в более ранних не надо(sysctrl).

AlexeySyS
()
Ответ на: RE: от Murr

>В MSDN по performance monitoring API искать не пробовал? ;)
Не пробовал, но попробую, а то гугл и прочие только беззастенчивую рекламу всяких утилиток выдают (если дело касается виндозы) ;)

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

200000 одновременно открытых сокетов )

> все эти - тесты дерьмо! лучший тест - реальная жизнь.

> вот вы супер-крутые БСДешники, обясните, как такая глючная, кривая поделка для красноглазых под названием ляликс может держать одновременно 200000 коннектов на серверах p2p в сети ed2k? ААА?

1. В TCP/IP каждый "коннект" это занятый сокет

2. Число сокетов в ОС - 65536, ибо стандарт ( при этом неважно, как реализована сетевая подсистема - BSD socket или streams XTI )

3. Реальное кол-во одновременный соединений по некоторым причинам (уточнять не буду - поверь на слово) ещё меньше.

4. Поднять этот предел никакими настройками sysctl и пр. НЕЛЬЗЯ

PS: Всё вышесказанное справедливо для ЛЮБОЙ системы.

DS: убей в себе ламера 8)

loki
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.