Все-таким 2.6.32 - весьма почтенное, хоть и работоспособное ведроНе стоит вестись не номер ядра в RH и иже с ним. Нумерация ради соблюдения legacy и про реальное положение дел не говорит. Там довольно много бэкпортированного свежака. Протестированного, нормального, работоспособного свежака.
единственная опенсорсная субддаже если уточнить что РСУБД, то далеко не единственная. Другой момент, может быть, если хорошо подумать топикстартеру, ему реляционная база не нужна и подойдёт noSQL.
это не очень верный ответ, т.к. неизвестно какие типы движков используются. если не используется MyISAM то нет смысла ему выделять память, и наоборот.Можешь это ребзям из Перконы рассказать. Это их рук дело. Они вроде как спецы, поэтому даже не протестую, когда работаю с их планировщиком конфигов.
innodb-buffer-pool-size над делать под размер базы или чуть с запасом на вырост - цель чтобы mysql мог держать всю базу в памяти, если памяти больше чем размер базы.А операционка всё до последнего аллоцирует, ничего не зажмёт, не посчитает, что вот этот файл из /var/lib/mysql/..., к которому давно не было обращений, пусть полежит на диске?
надо выделять памяти под завязку, за вычетом нужд системы и других процессов.есть приблизительные формулы, но у них один общий недостаток - они приблизительные.
250 коннектов тоже непонятно почему столько? каждый коннект жрет память под буфера, если реально максимум до десятка соединений то такой запас не нужен.процессы php-fpm на скрине указывают, что это всё-таки вэб-проект. Есть мнение, что сервер проектировался минимум под 10 одновременных подключений в секунду, и совсем только не 10 уникальных адресов. Поэтому 250 может быть ещё маловато.
А если выделить памяти больше, чем ее есть физически можно доиграться до OOM killerВ случае, если обладатель сервера не самодур, знает и помнит про так называемые грязные и анонимные страницы памяти, а также про механизм свопирования, когда операционная система сбрасывает на диск давно не используемые страницы памяти, то он наверное создаст во время разбиения раздел подкачки или даже выделит под него отдельный быстрый диск. Да и ООМК не так уже плох, чем решение ОСи замораживать процессы при нехватке ресурсов.
mysql прекратит принимать часть коннектовЗдесь очень важным момент - коннекты изначально принимает и обрабатывает операционная система, её планировщики (сетевой, дисковый, ОЗУ) подготавливают, обрабатывают и закрывают взаимодействия с той или иной периферией, сеть и файловая система держат свои буфера в оперативной памяти и лишь потом приложение, которое принимает коннекты. Помимо прочего там могут быть и другие приложения, всякие вэб сервера и аппликухи, которые тоже памяти хотят. На скрине вот целых два php-fpm (7.2 и 7.1), не исключено, что и nginx там болтается, также BIND виден. Поэтому не известно, что раньше может прекратить принимать соединения.
На сколько я знаю, использование криптографических алгоритмов не сертифицированных ФСБ запрещено в РФ, кроме варианта встроенных в ПО или железо алгоритмов.Можно заюзать отечественные алгоритмы. Они дают очень достойное шифрование.
Разве Debian не "ляжет" под пиковой нагрузкой в 100к юзеров в месяц?Очень и очень многое не зависит от ОС. Оборудование, твои приложения, настройки - это вне зависимости от выбранной ОС может оказывать существенное влияние на производительность.
К слову, забыл спросить, какой нужен канал для этого, 100mb/s хватит или гигабит нужен?100к юзеров в день это приблизительно 1.2 запроса в секунду. Для такого "интенсива" хватит 10mb/s и w2003 сервера на скромном железе.
С одного клиента может идти от 7 до 200 пакетов в секунду. Система рассчитывается на онлайн в 10к юзеров. То есть получается до 2.000.000 pps.200×10000×8×1500 = 24000000000 бит/с. Или 24 Гбит/с для пакета ТСР. Это очень хорошо и круто.
Просто здравый смысл подсказывает что Java программа не выдержит и ляжет.Не кастомизированное ядро Linux при нормальных сетевых картах выдаёт порядка 300'000 pps или около 4 Гбит/с. У тебя довольно хорошая программа на Яве. С таким интенсивным трафиком может не справляться ядро. Если лишнее из твоей программы повыкидывать и допилить, а лучше переписать на Си, то получится неплохой балансировщик). Хотя не совсем представляю, как 20G обрабатывает твой балансировщик на недопиленном ядре и без кучи интеловских сетевух. Реально хорошая программа на Java))