Сегодня я пришел, чтобы еще раз поговорить с вами об одной из наиболее часто используемых веб-служб в мире: веб-сервере. Apache2.
Это тема, о которой говорили много раз, но теперь я хочу рассказать вам о еще одной особенности, которую следует учитывать при использовании этой услуги: Предел одновременных подключений. Неважно, у нас очень простой или космический корабль с процессором i7 и 32 ГБ оперативной памяти ...
Предел одновременных подключений всегда будет одинаковым, если мы не примем соответствующие меры, а это означает, что если мы хотим, чтобы одновременно подключалось много людей, нам потребуется не только хорошее оборудование, но и хорошая конфигурация.
При этом ничего устанавливать не нужно, все основано на простых концепциях, которые необходимо учитывать при настройке apache; концепции, которые должны быть очень ясны, прежде чем вы захотите внести какие-либо изменения.
Первое, о чем следует подумать: какой потенциал у моей команды? Сколько одновременных подключений может поддерживать мое оборудование, если я использую его с максимальной силой? Все это зависит от одного фактора; RAM (оперативная память).
Чем больше ОЗУ, тем больше количество подключений, хотя фиксированного значения (то есть, X клиентов для каждого X RAM) нет, поэтому в первую очередь важно выполнить небольшие вычисления на нашем веб-сервере с чтобы знать наши пределы.
Первое, что вы должны знать, это сколько ОЗУ в среднем потребляет каждое соединение с Apache, поскольку каждое установленное соединение предполагает определенное потребление ОЗУ в системе ... Очевидно, что не все соединения используют одну и ту же оперативную память, с которой нужно было бы создать media ... Все это можно получить с помощью следующей команды:
ps -ylC apache2 --sort: rss | awk '{СУММ + = 8 $; I + = 1} END {print SUM / I / 1024} '
Полученный результат будет представлен в мегабайтах и может варьироваться в зависимости от количества активных подключений, типа просматриваемых страниц и т. Д. Поэтому рекомендуется проводить тест с разными открытыми вкладками; каждый из них показывает различное содержание, если возможно. В моем случае, например, результат был 9.5458, что, если мы округлим его вверх, будет 10 MB ОЗУ потребляется в среднем на одно соединение.
Также важно знать, сколько оперативной памяти потребляется остальными процессами, активными в системе, поскольку веб-служба не единственная, которая работает в операционной системе, и необходимо оставить свободную оперативную память на сервере, чтобы она могла выполняться. остальные задачи. Это можно получить с помощью команды, показанной ниже:
ps -N -ylC apache2 --sort: rss | awk '{SUM + = $ 8} END {print SUM / 1024}'
Полученный результат также будет представлен в мегабайтах и довольно точно покажет нам объем оперативной памяти, потребляемой остальными процессами; в моем случае 800 MB. Обладая этой информацией, мы могли бы сделать общий расчет количества одновременных подключений, которые мы могли бы иметь; Я рассчитываю, что мы получили бы с помощью очень простой операции.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
Имея эту формулу в руках, представим, что у нас есть компьютер с 4 ГБ ОЗУ, то есть 4096 МБ, и что наш компьютер показал вышеупомянутые результаты; расчет будет:
(4096-800) / 10 = 329 одновременных подключений
Проблема с этим расчетом заключается в том, что он слишком экстремальный, поскольку он потребляет всю оперативную память (заставляя сервер использовать подкачку), а также, в случае наличия базы данных, такой как MySQL или любой другой, подключения к ней также будут потреблять RAM, с помощью которой полученное число можно было квалифицировать как утопическое число. Таким образом, чтобы освободить память для возможных дополнительных процессов, а также рассмотреть возможность выполнения подключений к базе данных, мы уменьшим количество подключений до 250.
Теперь, когда у нас есть максимальное количество одновременных подключений, нам нужно подготовить Apache для получения этого номера, что и делается в файле конфигурации этого вызова. apache2.conf, который размещен в / и т.д. / apache2.
Рассматриваемый файл следует структуре, основанной на модули, каждый с соответствующим именем, но нас будет интересовать только один из них, имя которого mpm_prefork_module. Рассматриваемый модуль по умолчанию имеет следующие данные:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
Этот модуль имеет ряд очень важных параметров, хотя есть один из них, который нас особенно заинтересует, называется MaxClients. Этот параметр указывает максимальное количество одновременных подключений и должен быть изменен на 250.
Следует принять во внимание одну деталь: когда в указанном параметре указано значение, отличное от значения по умолчанию, необходимо добавить еще одно значение ПЕРЕД этим. Этот параметр называется ServerLimit и устанавливает предел подключений, которые сервер может «удерживать», даже если он выходит за пределы лимита.
Параметр ServerLimit всегда должен быть немного выше, чем MaxClients, и здесь, поскольку места для маневра мало, предел 270. В результате модуль будет выглядеть так:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Теперь останется только перезапустить службу Apache с помощью команды:
/etc/init.d/apache2 перезапуск
Благодаря этому мы уже могли пользоваться нашим оптимизированным веб-сервером.
Привет.
Спасибо за сообщение!
Я рад, что ты нашел это полезным.
Привет.
Есть способ кластеризации с Apache и двумя серверами, вы можете объяснить, как это работает?
Хотя я читал некоторые теории об этом, я никогда не применял их на практике. Тем не менее, возможно, эта статья может дать вам некоторые рекомендации в этом отношении, хотя я повторяю, что у меня не было возможности применить это на практике:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
вы просили некоторое время, если вы не решили; У меня есть схема балансировки с третьей стороной, которая действует как файловая система, вы указываете папки, которые находятся в var / www / html / (в моем случае), в файловую систему, поэтому они разделяют ту же информацию, и вы, возможно, требуется виртуальный IP-адрес, который отвечает и перенаправляет на IP-адреса apache, для этого вы можете занять haproxy, и если вы хотите, чтобы он был в режиме высокой доступности, вы можете интегрировать поддержку активности на случай, если один упадет, другой продолжит отвечать, или также, если у вас уже есть домен для приложения, вы можете балансировать с фунтом, выполняющим бэкенды на обоих серверах, для конкретных случаев, таких как moodle или определенные приложения, которые подключаются к базе данных в mysql, вам нужно будет создать пользователя для каждого сервера приложений, который указывает на ту же базу данных .
Большое спасибо за пост, вы абсолютно правы, оперативная память - это первичный расчет, хотя я предполагаю, что мы также вычисляем максимальное количество процессов, которые может обработать наш процессор (конечно, сначала выполняя расчет основной памяти), и то, как будет распределяться диск жесткий (пример разделов / var = 1TR).
Вы правы; все важно, например, контроль температуры. Очевидно, что мощный процессор может выполнять большее количество задач одновременно с большой эффективностью, но целью этого поста было объяснить важность ОЗУ для количества одновременных подключений.
Хороший способ контролировать все эти факторы и посмотреть, не перегружен ли наш процессор или у нас мало свободной оперативной памяти, - это использовать сценарий bash. Возможно, вам интересен этот пост, который я сделал несколько дней назад об этом, и я оставлю его по следующей ссылке; Это глобальный мониторинг, но может быть кому-то интересно:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
привет
Очень хорошее примечание, большое спасибо!
Большое спасибо! Надеюсь, вы смогли этим воспользоваться.
Я не хочу быть придурком ...
… Но увеличивая количество подключений, вы не становитесь более уязвимыми для DDoS-атаки?
Это не тихий кретинский вопрос. На самом деле, увеличивая количество одновременных подключений, мы частично защищаем Apache от DDOS-атак, потому что вы должны учитывать, что количество максимальных одновременных подключений, установленных на сервере, является общим максимальным количеством подключений, а не исходящих из один пользователь. Таким образом, если вначале мы могли поддерживать только 150 одновременных подключений (независимо от того, являются ли они подключениями из законного источника или нет), теперь мы можем рассчитывать на столько, сколько поддерживает наш сервер, требуя одновременного подключения большего количества подключений без обслуживания. Очевидно, что увеличение максимального количества подключений - это не способ защитить себя от атак такого типа, скорее, следует реализовать политики брандмауэра. Если, например, веб-служба, которую вы хотите разместить, будет доступна в Интернете, мерой безопасности, которая может быть реализована, будет добавление этих строк в наш брандмауэр:
iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-upto 10 -m состояние –состояние NEW -j ПРИНЯТЬ
iptables -A INPUT -p tcp –dport 80 -m state –state ESTABLISHED, RELATED -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -j DROP
Одной из характеристик DDoS-атак является то, что злоумышленник может посылать пакеты с нескольких разных направлений, что не позволяет потоку пакетов идти только с одного направления.
Вы правы в том смысле, что брандмауэр, подобный тому, что я установил, не очень эффективен против DDOS-атаки, поскольку исходит из разных источников. Тем не менее, лучше ограничить количество подключений до 10 для каждого из этих источников, чем не иметь ограничения, что позволит каждому источнику установить сотню или более подключений.
В любом случае, вопрос заключается в том, что чем больше одновременных подключений поддерживает сервер, тем сложнее будет сбить его с помощью DDOS-атаки, что усложнит взлом страницы злоумышленником.
Привет.
Хорошо. А пока я продолжаю использовать NGINX на своем сайте, чтобы не мучить свой VPS.
Хороший пост @Drassill!
Я хотел внести свой вклад в нечто более статистическое, чем конфигурация.
Хотя самый простой и быстрый способ рассчитать параметр потребления - использовать среднее значение, возможно, мы могли бы быть более строгими и использовать «медианное значение» вместо «среднего». От чего это нас спасет? Что цифры исчезают, если соединение потребляет много памяти. Например, предположим, что следующие клиенты потребляют следующие значения в необходимых им единицах памяти (КБ, МБ, МиБ и т. Д.):
10, 15, 150, 5, 7, 10, 11, 12
В среднем будет около 30
И это потому, что у нас очень большой конец (150), а вычисления сумасшедшие. Медиана состоит из упорядочивания этих данных, деления количества выборок на 2 (наш центр) и последующего получения номера этой позиции. С этим у нас будет что-то вроде
5, 7, 10, 10, 11, 12, 15, 150
Таким образом, наше среднее значение будет: 8/2 = 4, то есть ~ 10
Здесь вы можете увидеть, что каким бы сумасшедшим ни был крайний случай, он всегда дает нам более реалистичное значение. Если мы добавим покупателя, который потребляет 200, наше среднее значение будет 11, а среднее значение может составить …….
Это только вклад, и это очень спорно, так как с соединениями, он не болтами.
Обнимаю людей linuxera 🙂
Здравствуйте, у меня была проблема на моем выделенном сервере, и это то, что каждый раз, когда количество примерно 250 человек в сети приближается, согласно аналитике Google в реальном времени, мой сервер как будто рушится, и соединение становится медленным, пока оно не разрывает соединение с веб-сайт и никогда не загружает больше, чем это количество пользователей онлайн, но когда я вижу производительность выделенного сервера, который составляет 8 ГБ ОЗУ, он показывает 10% использования, ЦП: 5% использования и жесткий диск: 1.99% использовать.
Вы можете мне помочь? Я не могу найти, что делать, эти шаги - решение?
Хороший Карлос.
Описанная вами проблема очень часто возникает, когда сервер не подготовлен должным образом. Ваш сервер, вероятно, будет принимать гораздо меньшее количество одновременных подключений, и когда он достигнет 250 подключений, он выйдет из строя. Следуя руководству, вы сможете решить проблему, хотя, если у вас есть база данных на этом сервере, вам также придется оптимизировать эту базу данных.
Привет.
Drassill, я выполнил указанную вами конфигурацию, и она была удовлетворительной, вчера я подключился к 280 пользователям, и сервер не отказал, я очень доволен этим результатом, и я также хочу сделать еще одну вещь, которую вы мне скажете, для оптимизации базу данных, ¿Как мне этого добиться?
Концепция базы данных довольно открыта; использование mysql не то же самое, что postgres (например). Очевидно, я не знаю всех баз данных; Я пробовал mysql и postgres, и увеличение количества одновременных подключений в них будет основываться на параметре max connections; Оптимизация mysql будет выполняться в /etc/my.conf, и параметр max connections должен быть изменен (среди прочего). Вместо этого для postgres у меня есть статья в моем блоге, в которой объясняется, как ее оптимизировать, которая может быть вам полезна или которую вы можете использовать в качестве справочника для своей базы данных:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Привет.
Здравствуйте, когда я кидаю первую команду, она показывает мне значение 0. Что это может быть?
Спасибо тебе за этот пост.
Какое хорошее руководство, эта информация является частью того, что я ищу... спасибо!
Но теперь, если я хочу, чтобы при превышении этих 250 посетителей посетитель 251 перешел на страницу ожидания или в виртуальную очередь, могу ли я сделать это в той же конфигурации?
Привет и спасибо!