сервер
- Thread starter Анжел
- Start date
ACETYLENE
Guest
Спрошу что волнует, раз уж компетентная компания собралась.
Кто какие пиковые нагрузки видел или считает достижимыми на апаче под убунтой (железо - AWS m1.xlarge)?
У нас получается до 300-350 клиентов, потом загрузка CPU и latency уже неприлично растут.
P.S. весь траффик HTTPS
T
Tanatos
Guest
Это у вас амазоновский инстанс же? Честно говоря, дел не имел с ними. И почему Убунта, а не Дебиан?
Нагрузки ваши мне представляются далекими от идеала. Апач способен на большее. Но тут четко надо понимать, что Апач, сам по себе, весьма прожорлив, в т.ч. "на будущее", и это его нормальное поведение, т.е. с ростом числа клиентов жор ресурсов Апачем не должен быть линейным, а отставать. Плюс важна тонкая настройка в зависимости от задач, если ставить по дефолту, то он и будет жрать по дефолту. Не знаю ваших потребностей, но в ряде случаев весьма выручает замена Апача на связку ngnix+php-fpm, она жрет значительно меньше и быстра. Но не всегда уместна.
Повторюсь, про амазон и внутреннюю кухню толком не знаю, можно ли там поковыряться, поэтому воздержусь от критики. А в качестве хостинга рекомендовал бы линоду.
T
Tanatos
Guest
Ну так и то хлеб. И потом, в результате общая производительность же все равно возрастет в условиях ограниченных ресурсов.
akern
Member
Попробуйте offload'ить https перед apache. Через тот же nginx
ACETYLENE
Guest
да
Насколько большее?
Можно без проблем получить в 2, 4, 8 раз больше мощности, с соответственным множителем цены
Но если это будет только на 500-700-1000 пользователей, то смысла конечно не имеет.
Это про какие ресурсы? по памяти вопросов нет, 30Мб на пользователя это вполне нормально. Только CPU - узкое место.
Там можно всё
А Линода с Амазоном тягаться ну никак не может, это слабовато для нас.
Last edited:
ACETYLENE
Guest
Да, это уже назрело решение, load balancer может расшифровкой заниматься ещё до серверов,
но там какие-то косяки были с передачей истинного адреса клиента дальше по цепочке... Наверняка решаемо, но нужно затратить время разработчиков.
T
Tanatos
Guest
Ну больше 500-700 не стоит, мы же говорим об одновременных? Из расчета примерно 28-32Мб на процесс, да, т.е. грубо 16Гб минус 3-4 резерв, 12000/32 = 375. Больше памяти - больше держим процессов. Но с пределом, конечно, возле 500-700. Т.е. на порядок количество не вырастет. Если есть возможность, то поиграйте с конфигом. Сколько у вас maxClients в конфе сейчас, наверное 256? Оно также непосредственно связано с serverLimit, min/max/spareServer. Плюс полезно посмотреть, сколько отведено на очередь - listenBacklog. Я бы аккуратно поднимал, скажем на полтинник, если у вас по дефолту 256, сначала 300, потом 350, 400 и т.д. Если система все держит отлично, можно еще поднять. Смотрим также complete/failed requests - в идеале последних не должно быть. Да и вобще было бы неплохо конфиг полностью пересмотреть, там за одну ниточку потянешь... Есть, конечно, кто ставит и 1000 и 1200, но это уже перебор, имхо, даже с учетом доступной памяти, лучше дополнительно поколдовать с очередью и keepalive параметрами.
Жрется в основном память. Причем апач сразу резервирует память на максимум процессов. Насколько растет загрузка CPU с ростом активных процессов, включая очередь, честно говоря не кажу, надо смотреть опытным путем. В принципе, если вы разгрузите с помощью ngnix - должно стать только лучше.
P.S. Linode вроде вполне достойные предложения имеет. Но верю вам на слово, т.к. опыта с амазоном просто нет.
UPD Да, как ни банально, но не забываем про БД. Если у вас БД используется по полной, то не забываем про кэширование и балансировку запросов. Ну и неоптимальные с т.з. обработки запросы способны нагружать систему. Но это уже вопросы к коду.
Last edited:
ACETYLENE
Guest
Конечно
Учитывая что трафик может внезапно вырасти система держится на уровне 70-75% от максимума, и получается что 350 от 500 не сильно-то и отличаются в этом случае.
Возможность-то есть, сложность в том чтобы сделать это одномоментно на сотне серверов и без потери клиентских соединений.
Посмотрю в понедельник, вернусь с цифрами
plan
Member
Какой брейкдаун потребления ресурсов CPU? user, system, wait? Мне так кажется, что если запустить top на хосте, то основной составляющей будет %wait. 300-350 клиентов это мало, апач ждет освобождения какого-то ресурса, а это тянет за собой латенси.Спрошу что волнует, раз уж компетентная компания собралась.
Кто какие пиковые нагрузки видел или считает достижимыми на апаче под убунтой (железо - AWS m1.xlarge)?
У нас получается до 300-350 клиентов, потом загрузка CPU и latency уже неприлично растут.
P.S. весь траффик HTTPS
Какие лимиты nproc и nofile для учетной записи, под которой бежит апач?
ACETYLENE
Guest
Я так детально не расследовал это дело, не знаю ответов.
Скажите как посмотреть (я конечно и погуглить могу, просто так быстрее будет)
Апач работает в связке с app-сервером на java, а она тоже ресурсов требует, я к тому, что это не просто "Hello world" показать, и java, и php, и необходимость иметь некоторый запас мощности приведут к тому что лимит пользователей будет намного ниже теоретически возможного...
T
Tanatos
Guest
Можно подобраться к нему как можно ближе.
Смотрите, сколько жрет ось, БД и все остальное, что крутится, рассчитываете примерно из расчета по 30 на процесс количество клиентов, т.е. 3-4 в резерв это уж так, на глазок, в реальности может и полтора хватит. Ну чуток еще в резерв накинуть. Сбалансировать конфиг, очередь. Тогда с учетом, что пиковые нагрузки не держатся круглые сутки, то и увеличение maxClient в два раза поднимет общую производительность значительно. Тем более на сотне то серверов.
ACETYLENE
Guest
Вы не поняли, пиковая нагрузка на систему в целом или не пиковая для отдельно взятого сервера не имеет никакого значения, потому что количество серверов будет подобрано load balancer'ом в соответствии с нагрузкой. И в идеале нагрузка на каждый сервер будет постоянной. Запас по мощности нужен не для того чтобы обслужить больше новых клиентов, а для того чтобы сервер продержался около 15 минут в условиях растущего трафика когда новые серверы уже запущены, но ещё не готовы принять трафик на себя.пиковые нагрузки не держатся круглые сутки, ... Тем более на сотне то серверов.
Повторюсь - проблем с памятью нет, половина пустует, только нагрузка на процессор.
T
Tanatos
Guest
Ясно. Посмотрите что у вас с процом по top, uptime и tload. Парсите /proc/stat.
Возможно не сбалансировано serverLimit, min/max/spareServer и queue со значением maxClient. Может еще БД тянет.
UPD Погуглил, велосипед не мой. Пригодится может?
plan
Member
уже app-сервер нарисовался. проблема может быть совсем не в апаче тогда
1. Лимиты учетной записи можно посмотреть с помощью ulimits -a. По дефолту количество процессов и open file handles 1024, это очень мало. Учтите, что любой открытый сокет это тоже файл. Поэтому, если планируете обслуживать тысячи хитов в короткий промежуток времени, то и число open file handles должно быть соответствующим.
2. помониторьте загрузку cpu. большой %wait будет индикатором bottleneck, надо будет уже дальше копать в чем проблема - какието эксклюзивные блокировки в ДБ, синхронный доступ к какомуто ресурсу application сервера, whatever?
T
Tanatos
Guest
проблема может быть совсем не в апаче тогда
Как я понял, там нет именно точного понимания, что конкретно грузит проц с увеличением нагрузки. Поэтому надо помониторить активно процессы и % нагрузки.
Если же "вина" Апача доказана - тут проще, активируем mod_status и имеем полное понимание, что там застряло костью в горле.
ACETYLENE
Guest
Вот само увеличение нагрузки и грузит проц
Ничего там не застряло, всё прекрасно работает, просто если есть возможность оптимизации и снижения расходов - надо попытаться.
Учитывая что тут можно выиграть 15-20% сейчас более перспективным видится покупка мощностей на AWS marketplace. Чем и заняты.
%wait крутится около нуля, кстати.
Вообще, если уйма свободного времени, или просто голова ничем не забита, то стоит попробовать несколько путей.
1 Ставим винду сервак, накручиваем иис или апач+мускуль+пхп, ставим файрволл, настриваем антивирь, выпрямляем конфиги апача, ставим патчи, ставим модули пхп, открываем нужные порты, делаем перенаправление. Качаем утилитки типа вэбспайдера, заливаем пару форумов phpBB + можно в довесок что-то на joomla, качаем пару эксплойтов и радуемся взлому или не)
2 Ставим линь, например фряху, накручиваем апач+мускуль+пхп настраиваем конфиги, ждем полного одеревенения системы, патчи и т.д. как и прежде, собственно пытаемся додолбиться до него с помощью утилит консольных, разрешается на виртуалку повесить gentoo или что-то такое простенькое, может попросить меня на DDos или кто во что горазд.
3 Все тоже самое (выбрать одно из двух), НО в промежуток ставим виртаулку, будет файрволлом, при ее отрубании, просто пропадет доступ к серверу, а поднять виртуалку, много проблем не составит.
Вообще тема обширная, но для теста вполне сойдет, опять таки многое зависит от типа проекта, и правильно выбранных составляющих, например тойже СУБД, почему мускуль, а не монго? или почему вынь а не линь?
1 Ставим винду сервак, накручиваем иис или апач+мускуль+пхп, ставим файрволл, настриваем антивирь, выпрямляем конфиги апача, ставим патчи, ставим модули пхп, открываем нужные порты, делаем перенаправление. Качаем утилитки типа вэбспайдера, заливаем пару форумов phpBB + можно в довесок что-то на joomla, качаем пару эксплойтов и радуемся взлому или не)
2 Ставим линь, например фряху, накручиваем апач+мускуль+пхп настраиваем конфиги, ждем полного одеревенения системы, патчи и т.д. как и прежде, собственно пытаемся додолбиться до него с помощью утилит консольных, разрешается на виртуалку повесить gentoo или что-то такое простенькое, может попросить меня на DDos или кто во что горазд.
3 Все тоже самое (выбрать одно из двух), НО в промежуток ставим виртаулку, будет файрволлом, при ее отрубании, просто пропадет доступ к серверу, а поднять виртуалку, много проблем не составит.
Вообще тема обширная, но для теста вполне сойдет, опять таки многое зависит от типа проекта, и правильно выбранных составляющих, например тойже СУБД, почему мускуль, а не монго? или почему вынь а не линь?
plan
Member
а значение %si (или %sirq) около чего крутится?
переведи на наш