Обработка файлов.xls с помощью Apache POI - Блог. Защита от F5. Настраиваем Apache правильно
Представляю вашему вниманию вторую статью из серии, посвященной процессу записи данных в СУБД Cassandra. В этот раз я планирую представить информацию о следующем компоненте — промежуточном кэше данных колоночных семейств.
Сразу же после помещения данных в Commit Log, информация также дублируется в структуру, называемую Memtable. Этот компонент имеет следующие свойства:
Теперь рассмотрим все подробнее. Чтобы лучше понять структуру Memtable, дополним иллюстрации из первой части обзора (). Напомню, что изображения созданы на подобии иллюстраций из официальной документации.
Принцип работы: процесс записи данных начинается с логирования всех операций в Commit Log, это необходимо для восстановления в случае сбоя работы узла. Сразу после этого данные дублируются в Memtable. Однако Memtable не осуществляет логирование, то есть точное запоминание вообще всех операций, а только хранит самые свежие данные. Это вполне логично с той точки зрения, что место в оперативной памяти значительно дороже, чем место на жестком диске. Исходя из того, что данные в Memtable упорядочены по ключу записи, а внутри ключа по колонкам, то наш рисунок можно усложнить соответствующим образом. Возьмем расширенный вариант схемы также из предыдущей части обзора процесса записи данных:
Для поиска и вставки новых элементов в Memtable используется алгоритм Skip List, вернее его реализация на Java — ConcurrentSkipListMap. Понимание принципа его работы не совсем обязательно в контексте изучения Memtable, однако этот алгоритм делает и без того быстрый поиск по оперативной памяти ещё быстрее и поэтому я вкратце постараюсь объяснить его основы.
Принцип работы алгоритма состоит в создании нескольких уровней с данными. На первом уровне находится список всех упорядоченных по возрастанию ключей. С определенной вероятностью какое-либо значение с первого уровня может быть продублировано на второй уровень. Значения со второго уровня также с некоторой вероятностью могут быть продублированы на уровень выше и так далее. Пропуски не допускаются — например, нельзя чтобы значение было на первом и третьем уровне, а на втором отсутствовало. При поиске элементов обращение сначала идет к самому высокому уровню, первое встретившееся значение сравнивается с искомым и если оно не равно ему, то спускаемся на уровень ниже и в зависимости от того меньше текущее значение искомого или больше, поиск идет в сторону убывания или возрастания элементов соответственно. Лучше всего этот процесс показывает анимация (кликните для просмотра) из статьи на Википедии:
Более подробно рассмотреть алгоритм по шагам можно в статье на Хабре и некоторых других источниках, а мы идем дальше.
К данным, находящимся в Memtable, впоследствии можно получать доступ как к кэшу при клиентских запросах чтения. Это также одно из отличий от Commit Log, к которому не могут осуществляться клиентские запросы.
Когда Memtable достигает определенного объема, происходит сброс (flush) данных в структуру, называемую SSTable, которая располагается на жестком диске. Регулировать максимальный объем Memtable можно с помощью параметра memtable_total_space_in_mb, который по умолчанию с версии Cassandra 2.0.2 стал равен четверти (ранее треть) от объема памяти, выделяемой для динамической памяти Java (Java heap size).
В свою очередь управление памятью Java осуществляет Cassandra самостоятельно и в зависимости от объема RAM устанавливаются следующие значения:
Many users new to Cassandra are tempted to turn up Java heap size too high, which consumes the majority of the underlying system’s RAM. In most cases, increasing the Java heap size is actually detrimental for these reasons:
— In most cases, the capability of Java to gracefully handle garbage collection above 8GB quickly diminishes.
— Modern operating systems maintain the OS page cache for frequently accessed data and are very good at keeping this data in memory, but can be prevented from doing its job by an elevated Java heap size.
If you have more than 2GB of system memory, which is typical, keep the size of the Java heap relatively small to allow more memory for the page cache.
Следующий параметр, отвечающий за работу Memtable — file_cache_size_in_mb . Судя по описанию в официальной документации, используется как промежуточный кэш для чтения данных (SSTable-reading buffer) перед их записью в SSTable.
Осуществлять гибкое управление Memtable можно с помощью параметров memtable_flush_writers и memtable_flush_queue_size . Первый параметр отражает количество (от 2 до 8 по умолчанию) экземпляров процесса, отвечающего за сброс данных на жесткий диск. Если у вас множество каталогов данных, большой размер Java heap или в в процессе перемещения данных из Memtable на HDD участвует множество жестких дисков, рекомендуется увеличить это значение и таким образом распараллелить процесс. Это актуально также при использовании SSD. Второй параметр задает максимальное количество полных Memtable, ожидающих сброса на жесткий диск. Его рекомендуют устанавливать в значение, которое равно максимальному количеству индексов какого-либо колоночного семейства. Эта рекомендация связана с особенность хранения индексов: индекс для колоночного семейства — это фактически ещё одно колоночное семейство, ключом которого является индексное поле оригинального CF:
At the storage layer, a secondary index is simply another column family, where the key is the value of the indexed column, and the columns contain the row keys of the indexed table…
…Cassandra co-locates index entries with their associated original table keys.
Стоит отдельно рассмотреть изменения касательно Memtable, которые были введены в версии Cassandra 2.1. Если до этой версии Memtable располагались исключительно в Java heap, то теперь можно переместить буфер Memtable в собственную память Cassandra. В связи с этим были добавлены соответствующие переменные в параметры конфигурации. Параметр memtable_allocation_type определяет три новых значения (первое я пропущу, поскольку оно соответствует типу хранения до версии 2.1):
multiple memtables may exist for a single column family, one current and the rest waiting to be flushed.
Однако остается вопрос что значит «полная Memtable» (full memtable) и почему рекомендуется устанавливать значение параметра memtable_flush_queue_size к максимальному количеству индексов для одного колоночного семейства:
The number of full memtables to allow pending flush (memtables waiting for a write thread). At a minimum, set to the maximum number of indexes created on a single table.
Возможно имеет место следующий алгоритм: когда одиночный сегмент commit log достигает своего максимального объема, создается новый файл commit log (один для всех CF) на жестком диске и новые Memtable (по одной для каждого CF) в оперативной памяти. Одновременно старый commit log помечается битом 0 (то есть ожидает операции flush). Если будет достигнут один из максимальных пределов — commitlog_total_space_in_mb для commit log и memtable_total_space_in_mb для memtable, самые старшие полные memtable начинают помещаться в очередь (memtable flush queue) и после их сброса на диск в SSTable, удаляются (точно также и соответствующие им commit log). Это лишь мое предположение на основе той информации, которую мне удалось найти в сети.
Модуль Apache MPM расшифровывается как Apache Multi-Processing Module, что в переводе означает «Модуль мультипроцессовой обработки». Обычно по-умолчанию в Apache используется модуль MPM prefork .
Определить, какой именно менно модуль Apache MPM используется, можно следующей командой:
Httpd -V | grep mpm -D APACHE_MPM_DIR=»server/mpm/prefork»
Или на системах, подобных Debian, где сервер называется apache2 :
Apache2 -V | grep mpm -D APACHE_MPM_DIR="server/mpm/prefork"
Рассмотрим настройку параметров модуля Apache MPM prefork , исходя из объема оперативной памяти на хосте. Определим средний размер памяти, занимаемый одним процессом Apache:
Ps -ylC httpd | awk "{x += $8;y += 1} END {print "Apache Memory Usage (MB): \ "x/1024; print "Average Proccess Size (MB): "x/((y-1)*1024)}"
На системах, где сервер Apache представлен демоном apache2 , замените в строке httpd на apache2 .
Команда покажет общий объем памяти, потребляемой всеми процессами Apache и средний объем памяти на один процесс. Примеры:
В дистрибутивах, подобных Debian:
User@debian:~$ ps -ylC apache2 | awk "{x += $8;y += 1} \ END {print "Apache Memory Usage (MB): "x/1024; \ print "Average Proccess Size (MB): "x/((y-1)*1024)}" Apache Memory Usage (MB): 231.531 Average Proccess Size (MB): 13.6195
Лучше эту команду выполнить несколько раз, и желательно тогда, когда ваш сервер будет находиться под максимальной нагрузкой, чтобы определить средние значения под нагрузкой.
Теперь, зная средний объем памяти, используемый сервером Apache, и зная объем физической памяти, можно вычислить значение MaxClients , которое задается в файле конфигурации сервера Apache httpd.conf .
Допустим, на вашем VPS или VDS сервере 1 Гб оперативной памяти, и вы хотите оставить 512 Мб для остальных процессов, отдав серверу Apache 512 Мб.
Предыдущая команда выдала результаты:
# ps -ylC httpd | awk "{x += $8;y += 1} \ END {print "Apache Memory Usage (MB): "x/1024; \ print "Average Proccess Size (MB): "x/((y-1)*1024)}" Apache Memory Usage (MB): 64.3789 Average Proccess Size (MB): 10.7298
Т.е. на один процесс Apache в среднем уходит 10 Мб памяти. Определим значение MaxClients:
MaxClients = Весь объем памяти для Apache / Объем памяти на один процесс
MaxClients = 512 Мб / 10 МБ = 50.
Теперь мы знаем самое важное значение параметра модуля Apache MPM prefork , задающее максимальное число дочерних процессов таким, чтобы не была "съедена" вся оперативная память, а только часть ее (в нашем примере - половина, равная 512 Мб).
Внесем данные в файл настроки модуля Apache MPM prefork, обычно располагающийся по пути /etc/httpd/conf/httpd.conf :
Краткое описание параметров модуля Apache MPM Prefork:
StartServers - число дочерних процессов, создаваемых при запуске сервера.
MinSpareServers - минимальное число неиспользуемых (запасных) дочерних процессов сервера, ожидающих потенциальные запросы.
MaxSpareServers — максимальное число запасных процессов, ожидающих потенциальные запросы. Если это число будет превышено, лишние процессы будут убиты.
MaxClients — самый важный параметр модуля MPM prefork, устанавливает верхний предел количества одновременно активных процессов. Именно от него зависит потребление памяти. Его значение перекрывает значение предыдущих параметров.
ServerLimit обычно равен MaxClients.
MaxRequestsPerChild - как часто сервер перерабатывает процессы, убивая старые и начиная (запуская) новые. Полезен при утечках памяти Apache и его библиотек.
KeepAlive - обеспечивает долгоживущие сессии HTTP, позволяющие отправлять несколько запросов через одно и то же соединение. Полезно включить, если страницы содержат много изображений.
Также есть хороший скрипт check_httpd_limits.pl , написанный на Perl, позволяющий определить, сколько памяти занимают процессы сервера Apache . Скрипт выдает предупреждения (или ошибки), если установленные в конфигурации Apache пределы памяти превышают размеры доступной памяти на сервере.
Нажав клавишу F5 в окне браузера и удерживая ее в течении нескольких минут вы можете устроить легкую DDOS атаку на сайт. Функциональная клавиша F5 дает команду браузеру перезагрузить страницу.
Если вы ее нажали и удерживаете длительное время, то ваш компьютер пытается загрузить ее (страницу) много и много раз, чем создает нагрузку на сервер в виде множественных запросов. А так как возможности любого сервера не безграничны, то от переизбытка «чувств» запросов он может перестать работать.
Зависнет сервер или нет зависит от технических характеристик и настроек самого сервера, сайта и используемой CMS. В этой статье я опишу как правильно настроить вэб-сервер Apache2 чтобы даже самый скромный сервер VDS с 512 МБ памяти справлялся с большим количеством запросов, в том числе вызванных клавишей F5 .
Подготовка к настройке сервера
Определим какой модуль MPM использует Apache2. Для CentOS это выглядит так:
# httpd -V | grep MPM
Получаем ответ:
Server MPM: Prefork -D APACHE_MPM_DIR="server/mpm/prefork"
Отлично, у нас Server MPM: Prefork
Настройка Apache, что бы не было проблем с жором памяти
В CentOS надо отредактировать файл /etc/httpd/conf/httpd.conf .
Который по-умолчанию может иметь следующее содержание:
Краткое описание параметров модуля Apache MPM Prefork
- StartServers — число дочерних процессов, создаваемых при запуске сервера.
- MinSpareServers — минимальное число неиспользуемых (запасных) дочерних процессов сервера, ожидающих потенциальные запросы.
- MaxSpareServers - максимальное число запасных процессов, ожидающих потенциальные запросы. Если это число будет превышено, лишние процессы будут убиты.
- MaxClients - самый важный параметр модуля MPM prefork, устанавливает верхний предел количества одновременно активных процессов. Именно от него зависит потребление памяти. Его значение перекрывает значение предыдущих параметров.
- ServerLimit обычно равен MaxClients.
- MaxRequestsPerChild — как часто сервер перерабатывает процессы, убивая старые и начиная (запуская) новые. Полезен при утечках памяти Apache и его библиотек.
- KeepAlive — обеспечивает долгоживущие сессии HTTP, позволяющие отправлять несколько запросов через одно и то же соединение. Полезно включить, если страницы содержат много изображений. Но если используете NGINX как проксисервер, то оставьте значение OFF .
Самый важный параметр = MaxClients , он как раз и говорит о количестве одновременных процессов вебсервера Apache.
Как узнать значение MaxClients
Определить его значение не сложно. Расчет значения приведу для сервера с размером оперативной памяти 512 МБ. Решаем, что отдаем для ресурсов Apache 50% оперативной памяти, то есть в нашем случае 256 МБ.
Определяем сколько памяти отжирает один процесс:
# ps -ylC httpd | awk "{x += $8;y += 1} END {print "Average Proccess Size (MB): "x/((y-1)*1024)}"
Получаем следующие значения:
Average Proccess Size (MB): 21.5185
Получается, что в среднем один процесс Apache потребляет 21 МБ. Соответственно в отведенном объеме 256 МБ мы можем запустить 12 процессов.
Исправим файл конфигурации под новое значение:
С разрешения уважаемых коллег, хотел бы задать чайниковский вопрос.
Apache, как я понимаю, под каждое соединение создает отдельный HTTPD процесc. Процесс кушает немало памяти. Например, Linux Mandrake 7.0 предложила мне по умолчанию конфигурацию с mod_perl, mod_php, в которой вместе с моими скриптами каждый HTTPD "кушал" ~10 MB. Без скриптов и mod_perl получалось ~5 MB.
В то же время, к серверу можно обращаться только при условии, что есть свободные соединения. Если все соединения уже заняты (все HTTPD-процессы кому-то отвечают), новый пользователь получает connection refused. А занято соединение до тех пор, пока все данные не уйдут к пользователю (возможно, по весьма медленному каналу) - и еще 15 секунд после этого (ради keep alive).
(Если я где-то выше грубо ошибся, поправьте чайника, пожалуйста!)
А таперь посчитаем...
Пусть у сервера посещаемость 800,000 pageviews в день (для круглого счета:). Это значит, что ежесекундно ему надо обслужить не менее 10 запросов на загрузку страниц и, вероятно, столько же (или больше) на картинки. Оставим пока картинки - они благодаря keep-alive, вероятно, обработаются одним из ждущих этого HTTPD. Но страницы почти наверняка запрошены разными пользователями. Каждый HTTPD, обрабатывающий такую страницу, "проживет" не менее 15 секунд - а скорее всего >30 секунд, если учесть медленный канал и картинки. И все это время он посвятит только одному из 800,000 pageviews. (Срок мог бы сократиться, скажем, до 2-3 секунд, если канал быстрый, а пользователь почти сразу переключится на просмотр следующей страницы - тогда keep-alive"овская пауза не будет задействована. Но это крайне маловероятно.)
Все сие означает, что для нормальной работы сервера необходимо 30*10=300 соединений - иначе начнутся connection refused. Умножаем на 5 MB и сильно удивляемся.
Неужели для сервера с посещаемостью 800,000 pageviews/day необходимо 1,5 гигабайта RAM???
А ведь с вычислительной нагрузкой, в описанной ситуации, легко справится слабенький PIII-500 (и то будет загружен максимум процентов на 30, если не злоупотреблять скриптами). Всего-то 10 страниц в секунду.
А если 8,000,000/day? Неужто без кластера, компьютеров на 10, такие сайты не работают?
Или же, попросту, популярные сервера пользуются чем-то более качественным, чем Apache? Скажем, IIS порождает под соединение не процесс, а только thread, и тратит на это копейки...
Спасибо.
Но я не спрашивал, как улучшить ситуацию:) Я спрашивал, откуда такие неувязки с памятью? Ну пусть даже не 5, а 3 MB - в принципе ничего не изменится. Неужели Apache в принципе не рассчитан на сервера с высокой посещаемостью?
У меня ситуация вообще немного другая: для моего WebWarper"а (в сегодняшней версии) необходим mod_perl, и сами скрипты WebWarper"а весят немало. Меньше чем 6-7 MB вряд ли можно сделать, из инх мегабайта 3-4 не shared. Зато меня практически не интересуют картинки... А до посещаемости 800,000, честно говоря, нашему проекту еще пилить и пилить: покамест никаких трудностей с памятью еще нет.
Просто, если мои рассуждения верны, то получается, что при аренде или покупке сервера под Apache надо исходить из того, что однопроцессорному PIII-650, если ты собираешься использовать его хотя бы на 50%, соответствует 2 гигабайта RAM. Хостеры на этот счет явно другого мнения:) Вот я и прошу просветить меня, где тут собака.
Или все популярные сервера ставят keep-alive 3 секунды и полагаются на то, что файлы к их аудитории уходят тоже за 3 секунды? Тогда, конечно, требования к числу соединений снизятся существенно. Но как можно гарантировать, что файл уйдет к пользователю быстро? У большинства ведь модемы.
А может, грамотные администраторы популярных серверов ставят Squid и предоставляют ему отдавать файлы по медленным каналам?
В общем, если у кого есть опыт администрирования популярных Apache-серверов, подскажите, какими телодвижениями обычно снимается описанная выше проблема с памятью.
Для начала немного внесу ясность насчет KeepAlive. Как я понимаю имелся ввиду KeepAlive Timeout т.е. время с момента когда обработан последний запрос в keepalive соединении до того как должен поступить следующий или соединение будет прервано. 2-3 секунды вполне для этого достаточно.
Что касается обычного Timeout - его тоже советую уменьшить, читайте доки.
Нормальный хост(Dual PIII 500 / 512) может обработать примерно 100-200 в зависимости от контента. Разумеется если все эти запросы cgi или php, да еще и с обращением к БД - другой разговор. Имеется ввиду графика, статический html(в т.ч. ssi) и немного скриптов.
У нас серйчас 13 веб-серверов в кластере, обрабатывает он примерно 60 млн запросов в сутки, при том типа text/* из них 10-20%(все ответы типа text/html парсятся нашим модулем к апачу). В пиковые дни обрабатывалось до 80 млн, это где-то 1500 Gb в день.
Насчет mod_perl - он для чего используется? Если у вас там обычные скрипты - попробуйте perlcc - иногда помогает. но лучше перейти на C и сделать DSO модуль к апачу, а если почти все запросы враппером обрабатываются - вкомпилить жестко.
Еще насчет Apache и fork() вообще. Как известно в последних версиях Unix(FreeBSD, Linux) fork использяет модель copy on write. Т.е. когда "весящий" 10 Мб в памяти процесс форкается - вся эта облась пямяти ни в коем случае не копируется. Только когда порожденный процесс изменит какие-то данные - скопируются страницы где расположены эти данные и там уже будут произведены изменения.
> Нормальный хост(Dual PIII 500 / 512) может обработать примерно 100-200
> в зависимости от контента. Разумеется если все эти запросы cgi или php,
> да еще и с обращением к БД - другой разговор. Имеется ввиду графика,
> статический html(в т.ч. ssi) и немного скриптов.
У меня действительно немного другая ситуация, причем нестандартная - иначе
я бы просто доверился стандартной конфигурации.
Основная задача нашего WebWarper"а - забирать странички с других сайтов, сжимать их и отправлять клиенту. Никаких собственных страниц или картинок, за редким исключением, наш сервер не выдает. Поэтому почти весь трафик связан со скриптами. А так как они написаны на Perl, я использую mod_perl.
Переписать на C и подключить к Apache - идея правильная, но (пока) нерентабельная. Продукт довольно быстро развивается, и это в нем пока куда важнее, чем двух-трехкратный выигрыш в быстродействии. А переписать на C 200 KB Perl-кода - не самая легкая задача:) Да и развивать программу, работающую в основном с HTML -текстами и HTTP -протоколом, IMHO , куда легче на Perl, чем на C.
Впрочем, параллельно разрабатывается облегченная версия на Java (сервлет) с гораздо более сильной клиентской поддержкой. Со временем, вероятно, она станет основной. Это будет отдельный вопрос - как оптимально исполнять сервлеты: ибо расходовать по экземпляру Apache на каждый запрос, только для того чтобы передать его сервлету, как-то не хочется.
Нестандартность ситуации не только в том, что почти все запросы обрабатываются скриптами. Есть еще одна особенность: эти скрипты отрабатываются принципиально МЕДЛЕННО. Работа скрипта WebWarper начинается с загрузки страницы по HTTP-протоколу с "чужого" сайта. Эта операция, по определению, медленная - в лучшем случае секунда, в худшем, если канал до сайта плох - десятки секунд.
Вся эта нестандартность увеличивает расход памяти на 1 соединение и количество требуемых соединений. Сейчас у нас всего-то 40,000 pageviews/day, а уже 20 соединений не хватило: частенько получали "connection refused". Пришлось поставить 40. Выходит, для 1,000,000 pageviews/day понадобится 1000? Это же никакой памяти не хватит. Даже если вкомпилировать WebWarper в Apache. Боюсь, что начиная с некоторого момента придется вообще отказываться от Apache в пользу своего сервера.
Я так догадываюсь, что для обычных сайтов мои расчеты некорректны. Во-первых, 90% запросов - это картинки, которые обслуживаются максимально "легким" сервером. Во-вторых, ставится небольшой KeepAlive Timeout, а все ответы Apache вначале идут в какой-нибудь буфер типа Squid, так что даже в случае медленного модема процесс Apache освобождается быстро - за пару секунд (а не за 30). Верно я догадываюсь?
> Еще насчет Apache и fork() вообще. Как известно в последних версиях
> Unix(FreeBSD, Linux) fork использяет модель copy on write. Т.е. когда
> "весящий" 10 Мб в памяти процесс форкается - вся эта облась пямяти ни
> в коем случае не копируется. Только когда порожденный процесс изменит
> какие-то данные - скопируются страницы где расположены эти данные и там
> уже будут произведены изменения.
А в каких точно версиях? Мой Linux Mandrake 7.0, похоже, не очень хорошо реализует эту модель (судя по общему расходу памяти).
Что насчет RedHat 6.2? RedHat 7.0? Эти операционки мне сейчас предлагают хостеры (мы переезжаем на новый сервер).
http://perl.apache.org/guide/strategy.html
Обнаружив, что память не экономится, я начал копать разные статьи про mod_perl. Обычно пишут, что startup.pl экономит память. Но что удивительно: в одной из статей (уже не помню, где) я нашел обратное утвеждение: расход памяти увеличивается (хотя "быстродействие возрастает"). Теперь я думаю, что этот вопрос как раз имеет отношение к "модели copy on write в последних версиях Unix". Видимо, моя Mandrake что-то с этой моделью недопонимает:)
Подскажите, в чем тут дело, если не трудно.
- снести линух и поставить фрю.
- C даст выигрыш в 5-10 раз по скорости и в 10-20 раз по памяти.
- свой сервер ничего не изменит, а простых апачей в 512 Mb памяти влезает 600-700 (т.е. коннекций).
- perlcc не пробовали? скорость получше и памяти жрет меньше. а mod_perl в таком случае выкинуть. php тоже (дырявый и тормозной).
да...20 коннекций это... ;-)
а если не поможет все это - или на C или разбить на несколько серверов(в вашем случае это 5 минут работы) :))
насчет squid - да, для сайтов типа каталогов и т.п. это пригодно, а там где динамический контент или хостинг - нет.
- И что будет?
- Не даст он такого выигрыша. По скорости - максимум вдвое (ибо сжатие страниц и так выполняется на C - библиотекой Compress::Zlib). По памяти выигрыш действительно будет солидный, но ведь имеет значение только общая экономия размера памяти, съедаемой HTTPD-процесса. А он сократится хорошо если вдвое (в основном за счет отказа от модуля mod_perl).
- Т.е. меньше мегабайта на штуку? Серьезно? Значит, мой Linux Madrake с его умолчательным Apache совсем криво настроен? Мне уже говорили в клубе, что 3-4 мегабайта на HTTPD - норма, но меньше одного мегабайта!.. А как этого добиться? И возможно ли это в сочетании с mod_perl? (Извините чайника:))
- mod_perl выкидывать нельзя. Процессор тут же заткнется, даже с perlcc.
> да...20 коннекций это... ;-)
Ну что вы хотите? Пока мы еще живем у маленького хостера AriadnaMedia. Только сейчас перебираемся на dedicated-сервер.
> а если не поможет все это - или на C или разбить на несколько
> серверов(в вашем случае это 5 минут работы) :))
На несколько серверов - это имеется в виду сделать кластер из нескольких компьютеров?
Пока это не нужно, но в некотором будущем, вероятно, придется.
> насчет squid - да, для сайтов типа каталогов и т.п. это пригодно,
> а там где динамический контент или хостинг - нет.
Я об этом и говорил. То, что подходит для популярных каталогов, не подойдет для меня.
Спасибо за комменатарии. Надеюсь, будут еще:)
last pid: 96362; load averages: 0.71, 0.67, 0.67 up 82+09:32:27 23:47:04
366 processes: 5 running, 357 sleeping, 4 zombie
CPU states: 11.2% user, 0.0% nice, 11.9% system, 2.9% interrupt, 74.0% idle
Mem: 117M Active, 132M Inact, 227M Wired, 19M Cache, 128M Buf, 1388K Free
Swap: 500M Total, 36K Used, 500M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
94453 webuser 2 0 1724K 1224K sbwait 0 0:01 0.44% 0.44% ehttpd
94601 webuser 2 0 1716K 1212K sbwait 1 0:00 0.15% 0.15% ehttpd
94726 webuser 2 0 1716K 1216K sbwait 1 0:00 0.15% 0.15% ehttpd
94658 webuser 2 0 1724K 1224K sbwait 1 0:00 0.10% 0.10% ehttpd
94673 webuser 2 0 1716K 1216K select 0 0:00 0.10% 0.10% ehttpd
это статистика с одного из наших серверов с апачем из которого много выкинуто
и в тоже время много всунуто. т.е. считай стандартный. так вот реально например
демон с PID 94453 занимает памяти 1724-1224=500 кб
если у вас жрет больше -остальное это mod_perl
еще в апаче в либах (src/lib/expat-lite) есть одна библиотека...кажется для поддержки XML или чего-то в этом роде. ВЫКИНУТЬ НАФИГ И ЗАБЫТЬ ПРО НЕЕ!!! памяти жрет немеряно.
кластер в вашем случае делать ненадо. достаточно примитивного load balancing методом round robin DNS
в данном случае сервера сами не содержат данных и поэтому ненадо спец. софта и(или) железа для возможности обработки любого запроса любым из серверов. также отмечу что в среднем запросы в данном случае равновесны. следовательно надо лишь поделить равномерно запросы между серверами. даже с учетом кеширования в случае RRD запросы делятся равномерно.
Хочу сказать Вам, Сергей Чернышев AKA DroukS:
Похоже, что в обычном fork линукс этого действительно не реализует, а только в vfork
fork из SysV и BSD несколько отличаются между собой, и это было
одной из причин перехода сановцев от BSD к SysV, так как тогдашние
процессоры (вроде речь о Мотороле шла) не поддерживали аппаратно требуемую
BSD-ым fork-ом фичу copy-on-write.
Даже сейчас fork из BSD выполняется намного быстрее, чем в линуксе.
Апачевцы из-за этого рекомендуют BSD.
Я правильно понял: в FreeBSD copy-on-write поддерживается, а в Linux (что RedHat 6.2, что RedHat 7.0, что Mandrake 7.0) - не поддерживается?
Т.е. это значит, что на 512MB RAM Apache с mod_perl сможет отработать 300-400 соединений под FreeBSD и гораздо меньше - порядка сотни - под Linux RedHat 7.0? Мой провайдер об этом умолчал, хотя рекомедовал RedHat 7.0 и уверял, что памяти мне хватит на несколько сотен соединений.
Вот что написано в конце мана на vfork под Линуксом:
The BSD manpage states: "This system call will be eliminated when proper system sharing
mechanisms are implemented. Users should not depend on the memory sharing semantics
of vfork as it will, in that case, be made synonymous to fork."
Т.е. BSD сделали vfork на время пока не синхронизируют с fork-ом.
HISTORY
The vfork() system call appeared in 3.0BSD. In BSD 4.4 it was made synonymous to
fork(), but NetBSD introduced it again, cf. http://www.netbsd.org/Documenta
tion/kernel/vfork.html . In Linux, it has been equivalent to fork() until
2.2.0-pre6 or so. Since 2.2.0-pre9 (on i386, somewhat later on other architectures)
it is an independent system call. Support was added in glibc 2.0.112.
Т.е. BSD синхронизировали с fork-ом, а Linux нет.
Судя по всему, действительно, в BSD fork
Хочу сказать Вам, Дмитрий Кольцов (tentura):
С чем связано высказывание - "тьфу...бред несу... vfork тут неприменим"?
Почему в Апаче неприменим vfork? Можешь в 3-х словах сказать?
потому как при vfork выполнение родительского процесса приостанавливается на время выполнения дочернего. это потому что они выполняются в одном адресном пространстве и оно не copy-on-write
а в BSD вызов fork и реализует именно copy-on-write
Если я, чайник, правильно понял уважаемых специалистов, то получается, что мне нужно просить своего провайдера с самого начала ставить FreeBSD?
Ибо под ним Apache будет расходовать в несколько раз меньше памяти?
А будут ли в FreeBSD нормально работать сервлеты? jakarta/comcat?
Мне же мой спец радостно рассказывал, что он поставил себе Mandrake не ковыряя, а сосед поставил себе фрю не ковыряя и он с Мандрейка флудящим пингом фрю уложил, а тот его не смог уложить. Правда, фря, конечно лучше его восприняла чем винды, но все равно.
На самом деле я вижу равное распространение как Линукса, так и Фри среди умелых админов и меня озадачивает то, что нет достаточно достоверных данных о тех или иных приемуществах одной системы перед другой.
Э-э. Может, я и чайник, но мне кажется, что нормальное расходование памяти - это О-ОЧЕНЬ сильное преимущество. Я, кстати, уже уговорил своего провайдера на Фрю - именно исходя из этого (и их techs полностью подтвердили, что Фря экономнее из-за copy-on-write),
Микрософтовцы построили свой сервер IIS не на процессах, а на нитях, поэтому на соединение он расходует считанные десятки килобайт (если не считать расход памяти скриптами). Чисто теоретически, это менее надежно - "кривой" COM -объект, вызванный в ASP , может "завалить" соседние нити. Но в 99,9% ситуаций это гораздо лучше, чем тратить мегабайты на соединение, подобно Linux. Кстати, не знаете, почему Apache не использует нити? Разве в Unix нет такого понятия?
Уважаемые коллеги, у меня был еще один вопрос про mod_perl, но от него как-то отвлеклись:) Может, все-таки подскажете? Цитирую себя:
Попутно: у меня возникло некоторое недоумение по поводу разделения памяти и mod_perl"овского файлика предзагрузки startup.pl Документация по mod_perl (http://perl.apache.org/guide/strategy.html) интенсивно советует использовать этот файлик, загрузив там все наиболее популярные модули. Утверждается, что при этом не только возрастет быстродейтствие, но и сэкономится куча памяти. На деле - ничего подобного - в моем Mandrake 7.0, наоборот, памяти съедается намного больше! А насчет быстродействия я вообще не понял: какая разница, когда компилировать скрипты? При обращении к серверу, даже без предзагрузки, они почти наверняка давно уже скомпилированы.
Теперь я догадываюсь, что дело тут именно в отсутствии copy-on-write на Mandrake"е.
Т.е. в FreeBSD действительно получилось бы намного меньше, чем без startup.pl? Память под скомпилированный код скриптов израсходовалась бы только один раз, а не тратилась бы каждым HTTPD?
Друзья, будучи, как выяснилось, не таким большим монстром в Юниксе, я попросил своего коллегу развеять мои опасения о Линуксе с уго форком и он это сделал - при форке копируется не вся область памяти процесса (как было давным-давно), а только таблица дескрипторов страниц, занимаемых процессом, соответственно, память, конечно используется, но не в том масштабе, чтобы так уж горевать.
Если вам так нужны нити, возьмите Roxen - он появился в портах, значит достаточно стабилен. То что он появился в портах говорит о его по крайней мере юзабильности. FreeBSDшники очень пекуться о надежности того что оказывается в портах, это не перловый CPAN , где половина модулей не собирается.
Поставили Roxen, начали копать. Первое впечатление - весьма грамотная и эффективная штука. Могучий язык Pike - какая-то помесь C и Java. Судя по документации, содержит FastCGI - а это, вроде бы, не хуже mod_perl.
Появилось желание реализовать серверную часть - в новой клиент-серверной утилите, долженствующей заменить нынешний WebWarper - не на Java-сервлетах, а на Pike.
Может быть, кто-нибудь с Roxen уже серьезно работал?
что замедляет работу Apache и как получить максимум от PHP?
Приложения, использующие архитектуру LAMP (Linux, Apache, MySQL, PHP/Perl), постоянно совершенствуются и все шире используются. Но системный администратор часто не имеет полного контроля за самими приложениями, поскольку они написаны кем-то другим. Эта статья сфокусирована на действиях, которые вы можете выполнить для оптимизации Apache и PHP.
настройка Apache
Apache - часть программного обеспечения, легко поддающаяся настройке. Он имеет множество функций, и каждая является ценной. Настройка Apache отчасти состоит в надлежащем распределении ресурсов и подразумевает отключение ненужных настроек.
конфигурирование мультипроцессорных модулей
Приложение Apache является модульным, в том смысле, что вы легко можете добавлять и удалять его элементы. Эту модульную функциональность в ядре Apache - управление сетевыми соединениями и отправку запросов - обеспечивают мультипроцессорные модули (Multi-Processing Modules, MPM). Модули позволяют вам использовать потоки или даже перемещать Apache в другую операционную систему.
Одновременно может быть активен только один мультипроцессорный модуль и он должен быть скомпилирован статически при помощи --with-
mpm=(worker|prefork|event).
Традиционная модель "один процесс на запрос" назвается prefork. Более новая, модель с потоками (thread), называемая worker, использует несколько процессов, каждый с несколькими потоками, для получения более высокой производительности при более низких накладных расходах. Наконец, event - экспериментальный модуль, который содержит особые группы потоков для различных задач. Чтобы определить, какой мультипроцессорный модуль вы сейчас используете, выполните
Выбор мультипроцессорного модуля зависит от многих факторов. Отключение модуля event до тех пор, пока он имеет экспериментальный статус, -- это выбор между потоками и их отсутствием. Внешне кажется, что использовать потоки лучше, чем использовать fork, если все основные модули являются безопасными потоками, включая все используемые PHP-библиотеки. Prefork - более безопасный выбор; если вы выбрали worker, вы должны провести тщательное тестирование. Рост производительности также зависит от входящих в дистрибутив библиотек и вашего оборудования.
Независимо от того, какой мультипроцессорный модуль вы выбрали, вы должны соответствующим образом сконфигурировать его. Вообще, конфигурирование модуля подразумевает определение, как Apache контролирует количество запущенных worker"ов, являются ли они потоками или процессами. Ниже показаны важные опции конфигурирования модуля prefork.
StartServers 50
MinSpareServers 15
MaxSpareServers 30
MaxClients 225
MaxRequestsPerChild 4000
В модуле prefork новый процесс создан при помощи запроса. Резервные процессы простаивают, чтобы общаться с поступающими запросами, что уменьшает время ожидания запуска. Предыдущая конфигурация запускает 50 процессов, как только стартует веб-сервер, и старается поддерживать в наличии от 10 до 20 простаивающих запущенных серверов. Жесткий лимит процессов определяется при помощи MaxClients. Даже если процесс может общаться с множеством последовательных запросов, Apache убивает процессы после 4000 соединений, что уменьшает риск утечки памяти.
Конфигурирование мультипроцессорных модулей с поддержкой потоков производится подобным образом, за исключением того, что вы должны определить, сколько потоков и процессов должно использоваться. Документация Apache дает разъяснения по всем параметрам и необходимым расчетам.
Выбор используемых значений подразумевает некий метод проб и ошибок. Наиболее важное значение - MaxClients. Цель состоит в том, чтобы разрешить достаточное количество процессов worker или потоков, чтобы сервер не занимался исключительно свопингом. Если поступает больше запросов, чем может быть обработано, то по крайней мере те, которые поступили, обрабатываются; другие блокируются.
Если MaxClients слишком высок, все клиенты получают недостаточно высокий уровень сервиса, поскольку веб-сервер пробует выгрузить один процесс, чтобы позволить выполняться другому. Установка слишком низкого значения приводит к тому, что вы можете необоснованно отказать в обслуживании. Проверка количества процессов, запущенных в момент повышенной нагрузки, и анализ объема памяти, используемой всеми процессами Apache, дает вам хорошую идею относительно установки этого значения. Если вы устанавливаете значение MaxClients выше 256, вы должны установить то же значение для ServerLimit; внимательно прочтите документацию по мультипроцессорным модулям, чтобы узнать о соответствующих предостережениях.
Настройка числа запускаемых серверов и наличие запасных зависит от роли сервера. Если на сервере выполняется только Apache, вы можете поставить невысокое значение, поскольку вы можете использовать машину в полной мере. Если система используется еще и базой данных или другим сервером, вы должны ограничить число запасных запущенных серверов.
эффективное применение опций и переопределений
Каждый запрос, который обрабатывает Apache, проходит через сложный набор правил, которые диктуют любые ограничения или специальные инструкции, которым должен следовать веб-сервер. Доступ к папке может быть ограничен IP-адресом для определенной папки, или могут быть сконфигурированы имя пользователя и пароль. Эти опции также включают обработку определенных файлов, например, если предоставляется листинг каталога, они определяют, как будут обрабатываться определенные типы файлов, или должен ли быть сжат вывод.
Эти конфигурации имеют вид контейнеров в httpd.conf, например,
AllowOverride None
Options FollowSymLinks
Эта конфигурация, ограниченная тегами
Последний сценарий - повод для беспокойства на двух фронтах. Первый - вопрос производительности. Если FollowSymLinks отключен, Apache должен проверять каждый компонент имени файла (каталоги и собственно файл), чтобы убедиться, что они не являются символьными линками. Это влечет дополнительные накладные расходы в форме нагрузки на диск. Сопутствующая опция FollowSymLinksIfOwnerMatch следует за символьным линком, если владелец файла тот же, что и владелец линка. Это оказывает такое же воздействие на производительность, как и отключение следования символьным линкам. Для наилучшей производительности используйте опции, приведенные выше.
Читатели, которых волнуют вопросы безопасности, уже должны быть обеспокоены. Безопасность - всегда компромисс между функциональностью и риском. В этом случае функциональность - это скорость, и риск предполагает неавторизованный доступ к файлам системы. Смягчающим фактором является то, что серверы приложений LAMP обычно предназначены для определенной функции, и пользователи не могут создавать потенциально опасные символьные линки. Если жизненно необходимо разрешить проверку символьной ссылки, вы можете разрешить это только в определенной области файловой системы:
Options FollowSymLinks
Options -FollowSymLinks
Теперь любой каталог public_html в домашнем каталоге пользователя имеет опцию FollowSymLinks, отключенную для этого и всех вложенных каталогов. Как вы видели, опции могут конфигурироваться на покаталожной основе через конфигурацию главного сервера. Пользователи могут самостоятельно отменить конфигурацию сервера (если администратором разрешено AllowOverride) через файл.htaccess. Этот файл содержит дополнительные директивы сервера, которые загружаются и применяются к каждому запросу каталога, в котором содержится файл.htaccess.
Несмотря на то, что директива AllowOverride препятствует пользователям в совершении тех действий, которые вы хотите им запретить, Apache по- прежнему должен искать файл.htaccess, чтобы выяснить, нужно ли что-нибудь сделать. Родительский каталог может определить директивы, которые должны быть обработаны запросом дочернего каталога, что означает, что Apache должен также исследовать каждый компонент дерева каталогов, ведущий к запрашиваемому файлу. По понятным причинам это является причиной высокой дисковой активности по каждому запросу.
Самое простое решение - не позволять любые переопределения, которые отменяют необходимость проверки Apache файла.htaccess. Любые специальные конфигурации затем помещаются непосредственно в httpd.conf. Ниже показано, что нужно добавить в httpd.conf, чтобы позволить проверку пароля для пользовательского каталога project, вместо того чтобы помещать информацию в файл.htaccess и надеяться на AllowOverride.
AuthUserFile /home/user/.htpasswd
AuthName "uber secret project"
AuthType basic
Require valid-user
Если конфигурация помещена в httpd.conf и AllowOverride отключен, интенсивность использования диска может уменьшиться. Каталог пользователя project может не привлечь большого количества обращений, но учитывайте мощь этого метода применительно к сайту, работающему с большой нагрузкой. Иногда невозможно исключить использование файлов.htaccess. в следующем примере выбор ограничен определенной частью файловой системы; возможность отмены также может быть ограничена.
AllowOverrides None
AllowOverrides AuthConfig
Теперь Apache все же ищет файлы.htaccess в родительском каталоге, но прекращает поиск в каталоге public_html. Например, если запрашивается файл /home/user/public_html/project/notes.html, то его успешное отображение произойдет только в том случае, если каталоги public_html и project будут найдены.
Уместно сделать одно последнее замечание относительно относящихся к отдельным каталогам конфигураций. Любой документ о настройке Apache дает указание запретить DNS lookup через директиву HostnameLookups off, поскольку попытки обратно разрешить соединения всех IP-адресов с вашим сервером - излишняя трата ресурсов. Однако любые ограничения, базирующиеся на имени хоста, вынуждают веб-север выполнять обратный lookup на IP- адресе клиента и прямой lookup на основании результата проверки подлинности имени. Поэтому благоразумно избегать использования средств контроля доступа, базирующихся на имени хоста, и, когда они необходимы, проверять их, как описано.
постоянные соединения
Когда клиент соединяется с веб-сервером, разрешается порождение множественных запросов по одному и тому же TCP-соединению, что уменьшает время ожидания, связанное с многократными соединениями. Это полезно, когда веб-страница содержит несколько изображений: клиент может запросить страницу и затем все изображения в течение одного соединения. Обратная сторона состоит в том, что процесс worker на сервере должен ожидать закрытия сеанса клиентом, прежде чем он сможет перейти к следующему запросу.
Apache позволяет вам определять, как будут обработаны постоянные соединения, называемые keepalives. KeepAlive 5 на глобальном уровне httpd.conf позволяет серверу обработать 5 запросов на соединение, прежде чем соединение будет насильственно прервано. Установка этого числа в 0 запретит использование постоянных соединений. KeepAliveTimeout, тоже на глобальном уровне, определяет, как долго Apache будет ожидать другого запроса, прежде чем сессия закроется.
Обработка постоянных соединений не является конфигурацией типа "один-размер-годится всем". Некоторые веб-сайты функционируют лучше, если keepalives запрещены (KeepAlive 0), а в некоторых случаях их включение может принести огромную пользу. Единственное решение - попробовать оба варианта и выяснить все самостоятельно. Тем не менее, разумно использовать низкий таймаут, например, 2 секунды, при помощи KeepAliveTimeout 2, если вы разрешили keepalives. Это даст гарантии, что любой клиент, желающий сделать другой запрос, будет иметь достаточное количество времени, и что процессы worker не останутся без работы, пока будут ждать другого запроса, который может никогда не поступить.
сжатие
Веб-сервер может сжимать вывод, прежде чем возвратить его клиенту. В результате уменьшается объем страницы, посылаемой по Интернету, но все это - за счет циклов CPU на веб-сервере. Для тех серверов, которые могут позволить себе высокую нагрузку на CPU, это отличный способ создания быстро загружаемых страниц - размер страницы может после сжатия уменьшиться втрое.
Изображения обычно уже сжаты, поэтому необходимо сжимать только текстовый вывод. Apache предусматривает сжатие при помощи mod_deflate. Несмотря на то, что mod_deflate может быть просто отключен, он содержит множество сложных моментов, которые описаны в соответствующей документации.
настройка PHP
PHP - движок, который запускает код приложений. Вы должны установить только модули, которые планируете использовать, и сконфигурировать ваш веб- сервер для использования PHP только для файлов скриптов (обычно те файлы, названия которых заканчиваются на.php) а не всех статических файлов.
кеширование кода операции
Когда запрашивается скрипт, PHP читает его и собирает в то, что называется код операции Zend, бинарное представление кода, который будет выполнен. Этот код операции затем выполняется движком PHP и теряется. Кэш кода операции сохраняет его и в следующий раз при запросе страницы вновь использует. Это экономит немало времени. Доступно несколько реализаций кэша кода операции доступны; я успешно использовал eAccelerator. Инсталляция eAccelerator требует наличия в компьютере библиотек разработки PHP. Поскольку разные дистрибутивы Linux помещают файлы в разные места, получите инструкции по инсталляции непосредственно с веб-сайта eAccelerator"а. Также возможно, что ваш дистрибутив уже содержит нужный софт, и вы должны просто установить соответствующий пакет.
Независимо от того, каким образом вы установили на своей системе eAccelerator, есть несколько вариантов конфигурации. Конфигурационным файлом обычно бывает /etc/php.d/eaccelerator.ini. Директива eaccelerator.shm_size определяет размер кэша совместно используемой памяти, где хранятся скомпилированные скрипты. Значение измеряется в мегабайтах. Определение подходящего размера зависит от приложения. eAccelerator предоставляет скрипт для показа статуса кэша, который включает использование памяти; 64 мегабайта - хорошее значение для начала:
Eaccelerator.shm_size="64"
Вы также можете настроить максимальный размер для shared memory, если выбранное вами значение не было принято. Добавьте
Kernel.shmmax=67108864
в /etc/sysctl.conf и запустите sysctl -p, чтобы настройки вступили в силу. Значение kernel.shmmax измеряется в байтах.
Если превышен объем выделяемой shared memory, eAccelerator должен удалить из памяти старые скрипты. По умолчанию это отключено. Директива
Eaccelerator.shm_ttl = "60"
устанавливает, что когда eAccelerator исчерпывает размер shared memory, любой скрипт, доступ к которому не был получен в течение 60 секунд, должен быть удален.
Другая популярная альтернатива eAccelerator -- Alternative PHP Cache (APC). Создатели Zend также имеют коммерческий кэш кода операции, включающий оптимизатор для дальнейшего повышения эффективности.
Вы конфигурируете PHP в php.ini. Четыре важных параметра настройки определяют, какое количество системных ресурсов может потреблять PHP, как показано в таблице 1.
Таблица 1. Параметры настройки php.ini, связанные с ресурсами.
Размер этих значений обычно зависит от приложения. Если вы принимаете от пользователей большие файлы, max_input_time может быть увеличен или в php.ini, или путем его переопределения в коде. Подобным образом, для программ, потребляющих большое количество CPU или памяти могут потребоваться более высокие значения. Цель состоит в том, чтобы уменьшить воздействие "прожорливой" программы, поэтому глобальная отмена этих настроек не рекомендуется. Другое замечание относительно max_execution_time: это относится ко времени, затраченному CPU на процесс, а не к абсолютному времени. Таким образом, программа, совершающая большое количество вводов/выводов и небольшое количество вычислений, может выполняться намного дольше, чем max_execution_time. max_input_time также может быть больше, чем max_execution_time.
Количество записей лога, которые может сделать PHP, может настраиваться. В продакшне экономят место на диске, отменяя все журналы, кроме самых критических. Если журналы необходимы для диагностики проблем, вы можете вернуть то журналирование, которое необходимо. Директива
Error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
включает журналирование, достаточное для выявления проблем, но удаляет из скриптов лишнюю информацию.
заключение
Эта статья сфокусирована на настройке веб-сервера, как Apache, так и PHP. С Apache главная идея состоит в том, чтобы исключить лишние проверки, которые должен делать веб-сервер, например, обработку файла.htaccess. Вы также должны настроить мультипроцесорный модуль (MPM), который позволит сбалансировать используемые системные ресурсы и простаивающие worker"ы для входящих запросов. Лучшее, что вы можете сделать для PHP - установить кэш кода операции. Наблюдение за несколькими параметрами настройки ресурсов также гарантирует, что скрипты не завладеют ресурсами и не замедлят работу системы.
Шон Волберг, старший сетевой инженер, P.Eng