Вопрос: Какое аппаратное обеспечение веб-сервера вы используете для обработки 100 Мбит / с + статических файлов?


В настоящее время я использую Amazon S3 для большей части моих статических файловых сервисов, но мой ежемесячный счет становится очень дорогим. Я сделал некоторые грубые вычисления, используя журналы и в часы пик, мое самое дорогое ведро Amazon обрабатывает 100 180 Мбит / с трафика. В основном изображения до 50K.

S3 чрезвычайно полезен, когда дело доходит до хранения и резервирования, но мне не нужно платить за пропускную способность и запросы GET, если я могу помочь. У меня много недорогой полосы пропускания в моем собственном центре обработки данных, поэтому я настроил сервер nginx как прокси-сервер кэширования, а затем загрузил кеш основной частью моих файлов (около 240 ГБ), чтобы мой диск не записывался как сумасшедший на пустой кеш.

Я попробовал перерезать, и мой мой сервер задохнулся,

Похоже, что у меня были проблемы с дисками - у этой машины есть 4 x 1 TB SATA диски (Barracuda XT), настроенные в RAID 10. Это единственное, что у меня было на руках с достаточным объемом памяти, которое будет использоваться для этого. Я уверен, что nginx настроен правильно, поскольку я уже использовал его в качестве кэширующего прокси для другого, меньшего ведра Amazon. Предполагая, что это достаточный объем трафика для одной машины, возможно, SSD стоит попробовать.

Если вы обрабатываете большое количество статических файлов, какое оборудование вы используете?

Дополнительная информация 

Файловая система: ext4, установленный noatime, барьер = 0, data = writeback, nobh (у меня есть резервная батарея на контроллере) Nginx: worker_connections = 4096, worker_rlimit_nofile 16384, worker_processes 8, open_file_cache max = 100000 неактивный = 60 м


5
2017-10-03 20:59


Источник


Вы уверены, что узким местом является ваша установка диска или вы сталкиваетесь с проблемами подкачки из переполненной системной памяти? - Cypher
Nope - без обмена и около 40 ГБ свободной памяти. - Casey
Итак ... мой вопрос был не "мои проблемы с дисками"? Это проблема (или ... они настолько сложны, что они скрывают любые другие проблемы). Мне просто интересно, что другие люди используют для обработки такого рода трафика. - Casey
Вы определили, насколько активно активна большая часть ваших файлов? Является ли тот же 5% файлов сервером в 95% случаев или является более четким? Потепление кеша блока может иметь большое значение, предполагая, что основная часть ваших запросов находится над набором файлов, который является хорошим бит, меньшим, чем объем оперативной памяти. - EvilRyry
Быстрая мысль: вы установили noatime? - BMDan


Ответы:


Я не думаю, что ваш диск является проблемой. Первый ncache nginx использует хранилище дисков для кеша. Таким образом, скорость диска будет одной из потенциальных причин проблем в зависимости от того, насколько горячий / холодный ваш набор данных, однако я не вижу причин, по которым вы не могли бы обслуживать 100 мб / сек с упомянутым вами оборудованием, re используя nginx.

Во-первых, я бы предположил, что ваши рабочие процессы были низкими, ваши employee_connections были, вероятно, слишком низкими, и вы, вероятно, не установили достаточно высокий уровень open_file_cache. Однако ни одна из этих настроек не вызвала бы высокий IO Wait и такой всплеск. Вы говорите, что вы обслуживаете <50 тыс. Изображений, и похоже, что 1/4 вашего набора может быть легко загружено ОС. Nginx, безусловно, не настроен оптимально.

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

Многое зависит от вашего набора данных, но, основываясь на данных, которые вы указали, я не вижу причин, по которым диск ввода-вывода должен быть подобен этому. Вы проверили dmesg и журналы, чтобы убедиться, что один из ваших дисков столкнулся с некоторыми ошибками ввода-вывода в то время? Единственное, что я могу подумать, что могло бы привести к тому, что шип превысил файловый файл nginx, который заставил бы его перейти в режим FIFO, открывая новые файлы.

Убедитесь, что ваша файловая система смонтирована с noatime, которая должна вырезать большое количество записей из вашей рабочей нагрузки.

В качестве примера машины, которая регулярно обрабатывает 800 мб / с:

# uptime
 11:32:27 up 11 days, 16:31,  1 user,  load average: 0.43, 0.85, 0.82

# free
             total       used       free     shared    buffers     cached
Mem:       8180796    7127000    1053796          0       1152    2397336
-/+ buffers/cache:    4728512    3452284
Swap:      8297568     237940    8059628

Quadcore Xeon:
    Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz

$ ./bw.pl xxx.xxx 2010-09-01 2010-09-30
bw: 174042.60gb

average 543mb/sec, peaks at 810mb/sec

=== START OF INFORMATION SECTION === Model Family:     Seagate Barracuda
7200.12 family Device Model:     ST3500418AS Serial Number:    6VM89L1N
Firmware Version: CC38 User Capacity: 
500,107,862,016 bytes

Linux 2.6.36-rc5 (xxxxxx)   10/04/2010  _x86_64_    (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.33    0.00    2.40    5.94    0.00   87.33

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             109.61     19020.67       337.28 19047438731  337754190

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.09    0.00    3.40   10.26    0.00   78.25

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             138.52     21199.60       490.02     106210       2455

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.74    0.00    3.25    9.01    0.00   84.00

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             125.00     21691.20       139.20     108456        696

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.75    0.00    3.12   14.02    0.00   78.11

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             154.69     19532.14       261.28      97856       1309

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.81    0.00    3.36    9.48    0.00   80.36

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             112.80     17635.20       309.00      88176       1545

MRTG:

http://imgur.com/KYGp6.png

Dataset:

# du -sh ads
211.0G  ads

# ls|wc -l
679075

2
2017-10-04 15:34



Зачем вам ncache кэшировать статические файлы на диске, которые уже находятся на диске? Ядро должно отлично выполнять кэширование работы. - EvilRyry
Его вопрос заявил, что у него Nginx в его центре обработки данных, кэшируя ведро S3. Мои данные просто показывают, что Nginx, работающий на достойном оборудовании, способен обрабатывать 8x, каковы его требования, что было второй частью его вопроса. Какую часть вы считали запутанной, поэтому я могу отредактировать свой ответ? - karmawhore
Awesome - спасибо за информацию о реальном мире. Я добавил к моему вопросу дополнительную информацию о конфигурации nginx и файловой системы. - Casey
Обработка около 1/3 запросов теперь как эксперимент, никаких проблем. Мое чтение IOPS составляет 120-140. - Casey
запустить iostat -x 5 5, вы нажимаете 100% (или близко к нему) на любом из дисков? worker_rlimit_nofile / worker_connections кажутся низкими для количества трафика, который вы нажимаете, но я не вижу ничего, что могло бы вызвать проблему. Я не помню, как nginx обрабатывает очистку LRU - возможно ли, что весь ваш контент истек в то время, когда ваш IO взлетел вверх? на что была рассчитана ваша жизнь? - karmawhore


Ваш. Диски. Соси. Точка.

  • Попытайтесь получить намного больше и намного быстрее дисков. SAS прекрасно сочетается здесь, как с doe Velociraptors.

  • Тем не менее, лучше всего получить ... SSD.

Вероятно, ваши диски составляют около 200 IOPS. С SAS вы можете получить примерно до 450, а Velocidaptors - около 300. SSD высокого уровня может получить вас ... 50,000 (без шуток - я действительно имею в виду 5 0 0 0 0 0 0) IOPS.

Сделайте математику;) Один SSD, без RAID, будет примерно в 62 раза быстрее, чем ваш Raid 10;)


3
2017-10-04 02:00





Мы обслуживаем около 600 Мбит / с сервера с SSD на бэкэнд, а nginx + лак на передней панели. Фактический процессор немного Intel Atom; у нас есть четыре из них за LB, выполняющих 600 Мбит / сек каждый (используя DSR). Возможно, это не подходит для каждой ситуации, но это было прекрасно для нашего случая использования.


1
2017-10-04 17:27





Используется ли машина, которой вы используете, достаточно бара, чтобы иметь рабочий набор файлов, кэшированных в ОЗУ?

Кроме того, вы посмотрели на что-то вроде лака? Nginx отлично подходит для обработки тонны соединений - но это не конечная с точки зрения кеширования и производительности системы.


0
2017-10-03 21:13





Добавьте еще больше дисков. Вы можете торговать скоростью одного диска с количеством дисков (до определенной точки): возможно, вы можете получить такую ​​же производительность с X дорогостоящими дисками SAS 15kRPM или с (гадать, а не значимыми значениями) X * 2 дешевых SATA 7k2RPM дисков. Вы должны сделать свою математику и посмотреть, что лучше для вас - и это также зависит от того, сколько вы платите за место в стойке и власть в своем центре обработки данных.

SSD предоставит вам все IOPS, которые вам понадобятся, но они не дешевы для массового хранения (поэтому их основной вариант использования - это база данных, например, рабочие нагрузки).


0
2017-10-04 08:51