У нас есть загруженный веб-сервер (> 5 миллионов обращений в день), который обслуживает около 500 000 уникальных файлов. Мы запускаем Apache на FreeBSD 7.2. Согласно iostat -x, узким местом, по-видимому, является скорость поиска дисков (мы используем RAID 1 с двумя вращающимися дисками).
Влияет ли тот факт, что Apache записывает журнал доступа на эти же диски на скорость чтения? Вы обычно добавляете отдельный шпиндель для бревен? Если да, то добавляете ли вы один шпиндель или RAID (очевидно, вы потеряете данные журнала, иначе, если диск выйдет из строя)?
Или нам следует отправлять журналы Apache через сетевой интерфейс на центральный сервер журналов? Я предполагаю, что, вероятно, это отдельный сетевой интерфейс, отличный от того, который обслуживает все эти HTTP-запросы?
Наличие загруженного веб-сервера, ведущего журнал к RAID 1, проблематично. Я не могу вспомнить, в какой именно момент нам пришлось полностью изменить нашу стратегию регистрации / архивирования, но это было где-то около нескольких миллионов обращений в день.
Мне пришлось перенести ведение журнала на диски RAID 0 и, чтобы преодолеть возможную потерю данных, я внедрил недавно разработанную Facebook технологию Scribe с открытым исходным кодом для перемещения журналов на централизованный сервер регистрации. Теперь у нас есть несколько сотен миллионов обращений в день, и мы перемещаем терабайты журналов из наших внешних интерфейсов через разметчик на центральный сервер журналов, который теперь значительно упрощает анализ этих журналов, построение графиков тенденций данных и мониторинг. Для ваших целей один сервер записи будет обрабатывать этот трафик и легко перемещать эти данные.
Проверять, выписываться: mod_log_spread2 порт mod_log_spread
mod_log_spread - это патч для Apache mod_log_config, который предоставляет интерфейс для распространения журналов многоадресного доступа. Он использует инструментарий группового общения Spread,
И отправьте журналы сборщику журналов.
Я бы сказал, вы ответили на свой вопрос. Обе ваши идеи должны улучшить производительность веб-сервера. Если вы добавляете дополнительные диски для журналов, они должны быть RAID 1.
Ведение журнала для такого количества обращений определенно будет иметь эффект, но степень воздействия зависит от размера и количества фактических запросов - если обслуживаемые файлы велики, то ведение журнала не будет иметь большого значения в целом, и это просто действие о необходимости читать файлы для их обслуживания, что вызывает конфликт ввода-вывода. Если запросы контента имеют тенденцию следовать обычному шаблону (многие люди запрашивают несколько последних файлов с относительно небольшим количеством запросов на более старый контент), то может помочь добавление дополнительной оперативной памяти, позволяя ОС хранить больше контента в кеше. Если запросы не следуют такому полезному шаблону (т.е. запросы контента за любой заданный период времени не имеют шансов уместиться в реалистичном объеме ОЗУ), то это, конечно, не поможет.
Если в узком месте ввода-вывода значительна активность журналирования, то перенос журналов на другое устройство, безусловно, поможет. Это устройство может быть другим диском / массивом на той же машине или в сети. Если вы не наполовину загружаете сетевую карту серверов в любой момент нормальной активности (что маловероятно - ваша внешняя полоса пропускания будет узким местом), то для этого не потребуется дополнительная сетевая карта, если только активность ведения журнала не будет удалена от интерфейса общедоступной веб-службы. включено, упрощает защиту (или иным образом лучше подходит для вашей сетевой конфигурации). Ненасыщенная сетевая ссылка не будет иметь проблем с задержкой в или из-за активности ведения журнала Apache, хотя, если бывают случаи, когда ссылка интенсивно используется в течение длительных периодов, процессы Apache могут в конечном итоге блокироваться на дополнительное время (что означает, что в время занятости), ожидая завершения записи журнала.
Если чтение содержимого является такой же (или большей) проблемой, как запись журналов, вы можете рассмотреть возможность использования RAID0 для содержимого. Возможно, вам придется усилить механизмы резервного копирования для копирования с дополнительным риском смерти одного диска, который приведет к потере всего массива. Вы можете смягчить это с помощью RAID10, но это будет означать использование четырех дисков, а не 2. RAID5 также может быть вариантом, поскольку при чтении он будет работать аналогично RAID0 и потребуется только один дополнительный диск, но это не рекомендуется, если содержимое часто меняется, потому что Проблемы с производительностью записи RAID5 [каждая запись блока становится как минимум одним дополнительным чтением (соседний блок (блоки) и дополнительная запись (для блока четности)] вас пинает. Также вам лучше не передавать файлы журнала в RAID5 для та же самая причина.
В итоге: перемещение журналов на другие диски (на той же машине или по сети) может помочь, так же как и перемещение основного содержимого в RAID0, RAID10 или RAID5 (улучшите свои резервные механизмы при использовании R0, будьте осторожны с проблемами производительности записи с R5). Больше оперативной памяти также может помочь, уменьшив потребность в фактических операциях ввода-вывода, если большинство запросов в заданный период времени относятся к подмножеству ваших данных, которые могут поместиться в RAM-с-фрагментом-для- запасной размер.
Добавление отдельных дисков для ведения журнала было бы довольно логичным шагом и обязательно в какой-то степени помогло бы вашей системе, однако я думаю, что сейчас самое время задуматься о будущем.
Посмотрите, как увеличился ваш трафик на сайте, какие темпы роста вы сохранили, и подумайте, где вы собираетесь быть через год или даже через 2 года. Если ваш сайт будет продолжать расти в популярности, тогда вы нам нужно будет начать рассматривать несколько веб-серверов, избыточность, высокую доступность и так далее. По этой причине я предлагаю вам рассмотреть возможность использования rsyslog (который находится в портах как rsyslog3) или аналогичного средства для обработки удаленной регистрации файлов на внутреннем сервере. Затем, когда вам нужно добавить дополнительный веб-сервер, это простая задача - скопировать настройки rsyslog с основного веб-сервера, и вперед. Она также дает вам журналы на, надеюсь, не слишком утверждала коробку, которая позволит вам проводить более детальный анализ.