Уважаемые господа железячники, может быть кто-нибудь тестил Intel сервера 64 bit?
Ситуация такая: требуется создать высокопроизводительный ftp сервер,
уже одна платформа есть, первый блин комом, так сказать

soft:Linux RHEL3 + proftpd
hardware: 32bit 2x Xeon 3 Ghz , 4 Gb RAM; наружу - локалка 1 гигабит.
дисковая подсистема: внешний массив HP, подключен через FibreChannel PCIx хост-адаптер,
общий объем 6 терабайт (два массива: массив SCSI RAID5 и массив SATA, каждый по 10 дисков)

В общем, естественно, в начале с виду усе круто работало, но когда юзеров стало больше и особенно когда подключили второй массив - стала система медленно работать. Не только по сети, но и внутри медленнее стали выполняться большие файловые операции (стали тестировать после жалоб юзеров).
Число одновременных сессий ftp коннекций от 1000 и больше. Операции в основном чтение (выкачивание контента)
А еще хочется и можно дисков добавить, но боюсь, что совсем умрет.
Подозреваю, что уперлись в шину.
Знаю, что настоящая масштабируемость - это кластеры.
Но вопрос, до них - помогла бы организация такого сервера на базе 64 bit машинки?
Вроде там такие вещи эффктивнее работают (в теории)
Может быть, кто-ниюудь сталкивался, тестил...

Итак: вычислительная нагрузка - невелика, требуется высокая пропускная способность i/o
для большого количества процессов. Существенно ли медленнее деградирует при этом Intel 64bit система?

Я не столь на саму 64bit адресацию надеюсь и даже не на возможность набить памяти (что недурственно, конечно).
Просто я слышал, что у этой архитектуры эффективнее шина работает по сравнению со старой архитектурой Intel 32. Ну типа как у RISCовых компьютеров, которые могут хорошо держать именно такие множественные нагрузки.
Известно, что у того же Sun на SPARC при увеличении таких нагрузок деградация нелинейная, а у Intel 32 - линейная. Вот и интересно - а Intel 64 как реагирует?

я думаю, в скорости обмена с хост-адаптером, т.е. с контроллером.
Проявляется естетсвенно сперва в том, что клиентов медленнее обслуживает, думали сеть - но внутри файлики тоже стали медленнее копироваться (специально потестили). Т.е. по факту - медленнее начала работать дисковая подсистема.

допустим, массив SATA медленнее. Без проблем. Но медленее стал работать и SCSI массив.
Логично предположить, что это может быть потому что шину дополнительно нагрузили или хост-адаптер.
Процессоры... вряд ли. Загрузка невысока.

более детально: массив HP Smart Array 1500 cs; всего в потенциале подключено 4 корзины,
была подключена первая 7x300 Gb SCSI RAID5
потом подключили вторую 6x500 Gb SATA RAID5

планируется удвоить, вот думаю - не просядет ли совсем.


понятно дело, что когда только подключаешь и инициализируется RAID5 (он умеет онлайн) - то все жутко медленно. Но вот он собрался, стало получше, но не как раньше. и интересно, что первый массив тоже стал медленнее работать. Жить можно, но тенденция нехорошая. Вот я и подумал - может, новая архитектура спасла бы.
Не исключаю конечно, что это сам Smart Array так отреагировал. Может, юзать стали интенсивнее.
Все может быть, я ничего не утверждаю, просто спросил :-)

miksoft
А там, случаем диск не помер?

Нет, точно все живые

miksoftЕсли отключить второй массив, то скорость первого вернется?
Вот это к сожалению проверить пока не удалось. Он рабочий как бы, издеваться особо не получается. Хотя конечно мысль хорошая.

прикольно. Но немного не то imho

По iostat вроде ничего сверхъестественного. Задача -в основном чтение.
и действительно
10-12 тыс Blk_read/s, в пике - до 20 тыс.
SATA 5-6 Blk_read/s

остальные цифры совсем невыдающиеся.

Но это imho для такой системы не предел и ее еще можно насиловать.
Скажем, у нас довольно загруженный сервер СУБД на внутреннем массиве RAID10 (SCSI, число дисков 2x3) (контроллер SRCU42x)
выдает на чтение стабильно 20-25 тыс Blk_read/s. Думаю, он-то послабее HP-шного монстра.

Так что вряд ли для самого внешнего массива это не предел, вряд ли мы уперлись в его производительность. С RAID5 чтение должно быть быстрым вроде. Опять же, 7 дисков в наборе - это ведь довольно хорошо с точки зрения производительности.
К сожалению, не смотрел iostat-ом до подключения второго массива. Все заранее не предвидеть :-)

Будем мониторить, катастрофы еще никакой нет, просто интересно, на что закладываться при построении таких систем.

Еще что гложет - поставили туда ext3. Возможно, какой-нибудь RaiserFS был бы быстрее? Просто особо с ним не работали...

кстати исходя из iostat - возможно, как раз c SATA корзинкой мы уперлись, как считаете?

Спасибо, Adekamer! Без проблем:


iostat -d -x -k


Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 12.90 44.79 9.50 30.80 179.20 618.07 89.60 309.03 19.79 0.09 1.05 0.78 3.13
/dev/sda1 0.13 2.14 0.29 0.83 3.40 23.79 1.70 11.90 24.18 0.10 8.73 4.41 0.50
/dev/sda2 0.49 7.45 3.37 14.81 30.90 178.37 15.45 89.18 11.51 0.19 1.04 0.52 0.95
/dev/sda3 12.28 35.09 5.46 15.10 141.90 414.59 70.95 207.30 27.07 0.06 1.90 1.08 2.23
/dev/sda4 0.00 0.11 0.38 0.06 3.00 1.31 1.50 0.66 10.01 0.08 18.19 3.50 0.15
/dev/sdb 1627.13 107.01 111.33 18.55 671.42 1004.57 335.71 502.29 12.90 0.11 0.34 0.13 1.64
/dev/sdb1 260.90 90.45 48.54 15.56 1654.54 848.17 827.27 424.08 39.04 0.03 0.56 0.12 0.78
/dev/sdb2 1366.23 16.56 62.78 2.99 1504.86 156.40 752.43 78.20 25.26 0.08 0.62 0.41 2.71
/dev/sdc 782.06 63.91 46.02 8.80 6.49 582.29 3.25 291.14 10.74 0.20 0.88 0.08 0.42
/dev/sdc1 782.06 63.91 46.02 8.80 6.49 582.29 3.25 291.14 10.74 0.20 0.88 0.08 0.42

vmstat 5 5

procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 9692 330308 2760664 0 0 0 2 6 5 3 3 5 4
1 6 0 9408 330388 2764740 0 0 7417 2198 4639 5508 33 16 41 10
0 3 0 9548 330464 2762212 0 0 7393 1463 4708 11214 33 15 42 10
2 0 0 9540 330528 2740396 0 0 7898 1167 4757 6939 32 18 40 11
0 2 0 9548 330600 2735204 0 0 7633 1523 4787 11256 35 17 40 9

кто есть ху:

/dev/sda - это диски сервера внутренний, зеркало 2x 70Gb SCSI 320 на контроллере SRCU 41L
/dev/sdb - это корзина SCSI внешнего массива (7x300 Gb SCSI RAID5)
/dev/sdc - это корзина SATA внешнего массива (6x500 Gb SATA RAID5)

Спасибо.
Так это и подозревается. проблема с i/o.

файловая система ext3

\~/ на питоне реализация будь спок - считает как надо :) Проверял :)

А по поводу сабжа - на себя надейся, а про коллег не забывай. Глупо не посоветоваться, если есть возможность. Тем более что система еще не деградировала и к тому же будет скоро закупка оборудования для аналогичной - так что есть повод крепко подумать.
Мне просто на работе чел сильно рекомендовал 64bit (аргументы я выше приводил) - именно для множественных нагрузок, для такой системы.

Насчет журналирования - я так понимаю, что это актуально больше при записи. Тут же нагрузка на чтение - в принципе, будет ли сказываться журналирование?
В принципе, можно убрать, благо система на UPS и т.п.
Сама система - это файлопомойка, типа контент-портала, т.е. коммерческих данных там нет, а лежит всякий софт, музыка, видео и картинки и т.п., которые сами же юзеры и закачивают. Файлообменник, в общем.

СУБД-ы у нас на raw, так что таких проблем не бывает. Пока они на внутренних массивов с SRCU42x контроллерами, но ежели сабжевый массив покажет себя хорошо - будем на него переводить и СУБД. Опять же - _столько_ коннекций к СУБД у нас не бывает. Ну, СУБД вообще отдельная песня, мы с ними как-то более-менее знакомы, а монстер-ftp в новинку.


Может быть вообще можно было RAID0 сделать. Тогда точно производительность бы подскочила. Но что-то я не доверяю этому виду массивов.
Т.е. оно конечно небо на землю не упадет, если инфа навернется (коммерческих данных нет), но будет неприятно.

Спасибо, буду думать, посмотрю sar (как раз за выходные нормальная загрузка будет, это публичный сервер)

все же подавляющее большинство обмена по ioststat получается на read, насколько я вижу.
конечно, юзеры тоже могут писать, но больше они качают.
Надо рассматривать dev/sdb и /dev/sdc, это массив. На sda только система, плюс туда местный программер поставил MySQL, отсюда может быть активность на запись. Ну еще логи, конечно, создают нагрузку на запись, это понятное дело (собсно, формально там не я главный, я им только железо помогал подключать, массив этот самый, просто сейчас обратились насчет производительности. Семь нянек, в общем :))
Щас доступа к системе не имею, что-либо смогу сныть только после понедельника.

кстати конечно мысль убрать оттуда этот mysql нафиг :) Если согласятся. По top именно он процессор имеет, естественно.