Монолитный Perl и виртуальные машины по 700 Гб оперативной памяти

Это плохая причина вандалить ОП и переименовывать тему.
Сначала ТС (дата регистрации – 11.09.23) создаёт тему в статьях, ну это ладно. Но пора бы знать, что вандализм здесь не приветствуется.
Всегда можно попросить удалить тему, и такие случаи бывали.

монолитный Perl в 16000+ потоков/процессов, MySQL, KeyDB, Memcached и еще туда сюда

даже я офигела. не, я много всякого видела. видела серверы с кучей процессов, но на жабе, или на плюсах, или, на худой конец, на Эрланге. но на перле - ни разу. даже стало интересно, что там такое количество перла делает, в итоге?

перл весьма эффективен в мелких задачах. когда он жуёт большие количества данных, он может жрать память. оптимизировать его трудно, сама возможность оптимизации сильно зависит от контекста задачи. силами девопса точно не решить. но, как посоветовали выше, поковырять настройки базы, посмотреть длинные запросы в логах, попробовать поиграться с кэшами и прочим, в общем-то, можно. вдруг что-то сработает.

Переписывай на C++

https://github.com/wbraswell/rperl

даже я офигела. … но на перле - ни разу. даже стало интересно, что там такое количество перла делает, в итоге?

https://a-parser.com/

как посоветовали выше, поковырять настройки базы, посмотреть длинные запросы в логах, попробовать поиграться с кэшами и прочим, в общем-то, можно. вдруг что-то сработает.

Если нагружает база, так можно хотя бы её на другой сервер перенести с более оптимальными IOPs.

но на жабе

https://github.com/fglock/PerlOnJava/releases

я не любитель жабы, если что. вообще ни разу. мне не нравится принцип виртуальных машин и псевдокомпиляции. я считаю его совершенно ненужным оверхедом. так что перл на жабе - это изврат.

ну и жаба на серверах совершенно ужасна. она сжирает столько ресурсов, что хватило бы на стопицот таких же реализаций на сишке, запущенных одновременно.

GraalVM AOT ?

даже я офигела. не, я много всякого видела. видела серверы с кучей процессов, но на жабе, или на плюсах, или, на худой конец, на Эрланге. но на перле - ни разу. даже стало интересно, что там такое количество перла делает, в итоге?

про 16 тыщ либо ТС откровенно привирает и там их на порядок-два меньше, либо в консерватории что-то совсем не так.

Вот представим, что там какой-то веб, подперный MySQL, KeyDB и Memcached. Вопрос: откуда берутся эти 16 тысяч? Самое очевидное, что там что-то на CGI (можно предположить что там FastCGI или PSGI, но тогда не особо ясно зачем Memcached) и в сервер одновременно долбятся 16 тысяч пользователей, и этот весь трафик благополучно уходит в MySQL. Я себе совершенно не представляю, какое должно быть оборудование, чтобы экземпляр MySQL тянул на нем 16 тысяч соединений (речь даже не про активные, что-то выполняющие в данный момент, а просто какие-то соединения): тысяча (одна) соединений к БД - это уже очень много, эти же соединения не в вакууме живут, а конкурируют друг с другом, как по бизнес-логике (т.е. через блокировки) так и за ресурсы (CPU, память, кеш в БД и пр.), что вот происходит, если поток/процесс БД держит блокировку, а планировщик ОС его снимает с выполнения, потому что нужно еще кому-то выделить время? Ничего хорошего тут не происходит совершенно, поэтому нельзя допускать, чтобы в БД количество соединений превышало какого-то разумного множителя на доступное количество ядер и «шпниделей». А тут речь идет о 16 тысячах! Наверняка если top запустить, то там показатель cs будет зашкаливать просто. Посмотрите прекраснейший case study на эту тему от Oracle: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing - там вполне себе доступно объясняется почему много соединений к БД - это плохо. А если это еще и CGI то оно БД еще постоянными хендшейками на подключение долбит.

Что делать в первую очередь?

• оптимизировать запросы в БД как качественно так и количественно
• снизить одновременное количество подключений до разумного (т.е. идем и перенастраиваем http-сервер, или кто там за него, чтобы одновременно пропускал на исполнение не больше сотни запросов, а остальные пусть дожидаются своей очереди)
• если это CGI, то срочно убираем его с глаз долой и начинаем использовать PSGI
• ну а дальше идем по хардкору уже

Откуда такие выводы, что это веб сервер, а не веб парсер, например?

я как жава-макака вещаю в контексте, который мне ближе, даже если это не веб-сервер, то как оно отменяет тот факт, что у БД нет никаких шансов вытянуть такое количество клиентов?

я как жава-макака

Надеюсь, JavaScript макака? Иначе я разочаруюсь в джавистах.

вещаю в контексте, который мне ближе, даже если это не веб-сервер, то как оно отменяет тот факт, что у БД нет никаких шансов вытянуть такое количество клиентов?

Как количество соединений парсера связано с количеством соединений с СУБД?

Очереди? - нет не слышали.

Пулы соединений? - тоже в первый раз.

https://perldoc.perl.org/Thread

Какая версия Perl используется?

Из одного случая ты каким-то образом экстраполируешь на все остальные. Раз в одном проекте помогло, то и во всех остальных поможет.

Это больше похоже на недостаток опыта, нежели богатый опыт. Когда люди молодые, мало опыта, мало что видели, им кажется, что есть куча серебряных пуль.

Упомянутые здесь микросервисы, определённый язык программирования (раньше Java, сейчас - Rust), замена реляционных баз на NoSQL, кэширование, ООП и паттерны, DDD и чистая архитектура, и так далее. Список можно продолжать до бесконечности, и он год от года меняется.

Однако в жизни так не работает, или не всегда работает. Во-первых, всё перечисленное надо уметь применять, и надо понимать, когда внедрение технологии необходимо, а когда - не нужно или вредно. Во-вторых, оно далеко не всегда решает все проблемы. Проблема может просто быть сложной.

Допустим, если код пишется уже 10-15 лет, как у ОП, то он однозначно будет сложным для понимания, даже если его писали квалифицированные люди. В таких долгоживущих проектах неизбежно накапливается сложность.

А если его ещё писали плохо квалифицированные люди (по некоторым другим признакам, это выглядит весьма вероятно), то за 10-15 лет они написали карточный домик, который будет рушиться от любого прикосновения.

Каждый, кто проработал в индустрии хотя бы 10-15 лет, наверняка сталкивался с такими проектами. И там не работают никакие «очевидные» подходы. Решение любой проблемы в таком проекте занимает от нескольких дней до нескольких месяцев.

Я посмотрел и дал, советы были очевидны (индексы + использование определённых фишек фрейворка + обход известных багов фреймворка)

Если бы все проблемы производительности решались созданием индексов, то авторы СУБД могли бы просто сделать, чтобы при создании таблицы создавался индекс по каждому полю. А чё таково-та?

Я, кстати, до сих пор встречаю кучу людей, которые именно так и делают: на каждое поле таблицы вешают индекс при создании.

Очереди? - нет не слышали.

конечно не слышали, мы тапком щи хлебаем, куда тут нам до высоких технологий. А если говорить уже серьезно:

очередь предполагает последовательную обработку событий, где-то допускается что оно может идти параллельно, а где-то уже нет (и это еще при условии, что эта очередь наполняется изначально правильно), условно если вопрос встает про деньги, то есть большая разница в какой последовательности эта очередь обрабатывается, т.е. при наличии событий «списать тыщу со счета» и «накинуть 2 тыщи на счет» их успешность очень сильно зависит от последовательности обработки. В целом же эти все очереди, что kafka, что прочие другие MQ, имеют выигрыш в сравнении с БД исключительно за счет того, что там принято забивать на ACID со всех сторон (т.е. тут как вычитывание сообщения приводит к его удалению, так и мало кто потеет по поводу создания durable queues, есть еще финт с DLQ, но кто это полноценно в приложениях обеспечивает и разбирает?) Но даже если очереди…, вы хоть раз интересовались тем, какие есть ограничения у той же kafka, молебна всех поклонников микросервисов? А вот там та же самая пресловутая тысяча партишенов - это считается, что уже большим количеством, ну и, соответственно, тысяча потребителей - тоже много, в реальности от БД никуда и не ушли, зато модно и молодежно. Не нужно тут про очереди рассказывать.

Пулы соединений? - тоже в первый раз.

где пулы у ТС-то? если бы у него были пулы, то он бы не использовал Memcached - тут же логика абсолютна прозрачная: если я умею хранить соединения с БД в памяти приложения, то мне ничего не мешает в память пихать и данные - мне совершенно здесь не нужен никакой внешний кеш - у возникает только потребность в получении сообщений об инвалидации данных.

Ну давай по делу: ты если правильно ответишь, то с этого себе квартиру купишь?

Если нет, то зачем ты там работаешь?

до сих пор встречаю кучу людей, которые именно так и делают: на каждое поле таблицы вешают индекс при создании.

теперь я знаю, какие гады научили Claude плохому =)

Если бы все проблемы производительности решались созданием индексов, то авторы СУБД могли бы просто сделать, чтобы при создании таблицы создавался индекс по каждому полю. А чё таково-та?

Нет, проблема таким образом не будет решена полностью.
Во всех СУБД разработчики постоянно улучшают алгоритм плана запросов.
Кстати весьма интересная задача …

Если бы все проблемы производительности решались созданием индексов, то авторы СУБД могли бы просто сделать, чтобы при создании таблицы создавался индекс по каждому полю

Это рецепт уничтожения производительности, а не повышения

sokolaa, у меня например к тебе претензий никаких нет, так как не знаю, какие задачи на тебя возложены, но вот трудно обсуждать в треде «чёрный ящик».
Более подробно можешь рассказать о проекте?

А причину найти? Профилирование, сбор метрик производительности.

Во всех СУБД разработчики постоянно улучшают алгоритм плана запросов.

интересно в каких же…

джва года ждал

интересно в каких же…

Во всех.

Во всех.

вот PostgreSQL разработчики предпочитают заниматься откровенным онанизмом и дрочить на дидов, которым по 80 лет уже, а никак не усовершенствованием СУБД. еще примеры будут?

В MS SQL алгоритм, формирующий план запросов постоянно улучшают …

Если бы все проблемы производительности решались созданием индексов, то авторы СУБД могли бы просто сделать, чтобы при создании таблицы создавался индекс по каждому полю. А чё таково-та?

наличие индекса всегда «смущает» некий «оптимизатор запросов», в разных БД он называется по-разному: в Oracle - это CBO, в PostgreSQL - sql engine, не суть, суть же в том что наличие индекса на колонке побуждает оптимизатор если не использовать этот индекс, то хотя бы рассмотреть возможность его использования, в каких-то случаях это приводит к печальным результатам, к примеру: объявление FK в базе подразумевает, что нужно создать индекс на соответствующую колонку, в противном случае при DML БД будет блокировать всю таблицу вместо небольшого кусочка индекса, что в свою очередь приводит к тому, что в БД появляются паразитные индексы, которые нужно обновлять при DML и еще оптимизатор их может подхватить. Вот в SAP в итоге FK не используются, и мы тоже не используем.

А причину найти? Профилирование, сбор метрик производительности.

ТС всю тему избегает об этом говорить. Зато вот он хочет на микросервисы попилить и эксперты насоветовали тоже самое.

Зато вот он хочет на микросервисы попилить и эксперты насоветовали тоже самое.

Этим путём запросто можно сделать всё много хуже чем было.

В MS SQL алгоритм, формирующий план запросов постоянно улучшают …

у Майкрософта откровенная погоня за лидером с целью если не приблизиться по уровню, то хотя бы по деньгам иметь паритет (тут лицензии - тут ваши издержки), у остальных же - «лапки», причем в PostgreSQL написано такое откровенное говно в этом плане, что волосы дыбом встают в попытке понять чего же они 20 лет делали.

в PostgreSQL написано такое откровенное говно в этом плане, что волосы дыбом встают в попытке понять чего же они 20 лет делали.

В Firebird практически в каждой версии новый алгоритм, формирующий план запросов.

При этом они правда всегда предупреждают, что нужно тщательно проверить производительность всех запросов, так как возможен и регресс в некоторых их них.

Создание оптимального плана запросов весьма достойная задача, но такое ощущение, что для её решения пока вокруг неё с бубнов танцуют и …

ТС всю тему избегает об этом говорить. Зато вот он хочет на микросервисы попилить и эксперты насоветовали тоже самое.

У ТС есть более полная информация о проекте, чем у нас.

А отвергать микросервисы «просто потому» - это точно такой же бред, как и ввязываться в них не думая.

Это рецепт уничтожения производительности, а не повышения

Я об этом и пишу, только как бы с очевидной иронией, которую почему-то не поняли, а приняли за чистую монету.

Ну или изучай перл и пытайся оптимизировать перловый код. Других вариантов вроде нет.

«Падает и сыпется» - это не вопрос оптимизации. У нас была система, в которой всё становилось колом под нагрузкой, её решали и добавлением памяти, и всевозможными тикетами и горячими линиями суппорта (типа 24х7). Вот из-за «оптимизации» точно не дадут всё с нуля переписывать.

11 сентября - Всемирный день трезвости и борьбы с алкоголизмом

Предлагаю ещё добавить борьбу с флудом в форумах.

каким-то тупым свитчом Dlink

Это уже намекает, что денег на рефакторинг он не даст. Раз даже на железо не хватает

или взломали, то решается это переразворотом контейнера за минуту

Не решается. Взломают точно тем же методом сколько понадобится раз

Девопс работает всегда в паре с разрабом

Точно. А если монолит всех устраивает, то девопс там как бы и не нужен. Ищи другую работу. Иначе, если не сможешь ничего поменять, тебя ждет только профессиональная деградация

Разве что тебе лично интересно пощупать хайлод на примере монолита. Посмотреть, где и во что упирается, почему запускается час (это ж бред, что-то явно не так) и т.д.

Мб я просто макака в переговоров

Тогда девопс не для тебя. Т.к. там нужны обе части - и техническая (инструменты и практики), и организационная (договариваться и убеждать)

Если бы все проблемы производительности решались созданием индексов, то авторы СУБД могли бы просто сделать, чтобы при создании таблицы создавался индекс по каждому полю. А чё таково-та?

Ты в самом деле думаешь что «индекс по каждому полю» это максимальное, что можно сделать в плане индексов? Если у тебя условие A=1 AND B=5, то наличие двух индексов (по A и по B) это конечно лучше чем ничего, но гораздо хуже чем правильный индекс (один, по A,B). Так что, если ты хочешь сделать все индексы, то надо не по каждому полю, а по всем вариантам перестановок полей местами (количество получившихся индексов - факториал от количества полей). И очевидно от этого и потребление дисков станет огромным и производитеьность вставок никакой.

А вот если бы «индексы по каждому полю» были достаточными, то да, создавать их дефолтно при создании таблицы было бы вполне хорошей идеей (разумеется, с возможностью от них недефолтно отказаться). И никакого заметного «уничтожения производительности», которого боится annulen, в большинстве случаев бы не случилось. Проблема именно в том, что индексы по отдельным полям часто не особо полезны и нужны по комбинациям, которые перебирать намного затратнее.

В Firebird практически в каждой версии новый алгоритм, формирующий план запросов.

вот то, что написано ниже нужно воспринимать исключительно через призму того, что я придумываю планы запросов лучше любой СУБД (тут, Oracle-таки может конкуренцию составить), основная проблема в том, что я читал cost based query transformations concept, а разработчики СУБД как-то до нее не успели дойти.

Основной вопрос: СУБД - она сейчас для кого именно? для некого аналитика или разработчика?

Условные 30 лет назад СУБД предсталяла из себя некий большой сервер, на котором лежали данные всего предприятия, каждый мог туда зайти, построить какие-то выборки, при этом эта же СУБД управляла доступом к таблицам и пр.

Сейчас же ситуация совсем иная:

• БД создается под приклад, а если там какие-то интересные данные и есть (на самом деле нет там ничего интересного), то реплицируем данные куда-то еще
• SQL изначально позиционировался как декларативный инструмент для аналитиков, позволяющий что-то из БД доставать, а вот мне как разработчику сейчас более важны контракты ACID (и то не все), нежели возможности SQL (вот хочу запросы в стиле ООП писать)
• все СУБД страдают от банального DoS, когда можно завалить БД банальным запросов вида: select count(*) from tbl t1, tbl t2, tbl t3... но именно тут как-то принято забивать не проблему, т.е. реальность такая, что БД - это-таки не проходной двор никакой и ей должен управлять разработчик
• теории про нормальные формы - это откровенный бред сивой кобылы: нам как разработчикам (да и бизнесу) куда интереснее, чтобы оно работало быстро, а не чтобы было «по науке»

в итоге мое мнение такое:

• БД строю исключительно я, и исключительно я принимаю решения о ее дальнейшем ее развитии
• дрочилы теорий СУБД могут идти дрочить в другом месте - мы тут бизнесу помогаем деньги зарабатывать, а соответствие академическим идеям нам тут совершенно не упало (на просторах интернета можно найти идеи про НФ5, которые даже не запускаются. НФ2 - еще куда ни шло, НФ3 - не нужно)
• в мою БД запрещен доступ аналитикам - пусть строят свои отчеты где-то в другом месте, при большом желании я с радостью залью в это место пару десятков терабайт (тут я возможно уже отстал от реалий и в действительности все разумные индивидуумы ровно так и делают последние лет 10)
• я ожидаю, что БД будет не сколько мне помогать, сколько не мешать, т.е. как запрос написан - так и выполняй, написан плохо - хорошо, я воспринял, пойду перепишу, только совершенно нечего мои хорошие изначально запросы превращать в откровенное говно, как то любит делать PostgreSQL

Как удобно выцеплять из сообщения то, что легко и приятно раскритиковать, игнорируя скрытую иронию и сарказм.

Вообще, мой посыл был в том, что оптимизация запросов к базе предполагает гораздо больше усилий, чем просто создать индекс. Хоть по колонке, хоть многоколоночный.

Но да, на свете полно дураков, гораздо больше, чем кажется, которые просто хреначат по индексу на каждое поле.

И тут опять же предположение, что проблема в индексах и в базе. А по сути, в сообщениях ТС толком нет информации ни об арихтектуре проекта (кроме того, что это монолит), ни о проблемах.

Все мы здесь занимаемся гаданием на кофейной гуще.

ничего подобного, на perl НУЖНО было реализовывать свое собственное ООП как хочешь без всяких петоновских self

Поправил, не благодари :)

Там уже добавлено железа на 700 Гб RAM. Страшно представить, сколько ещё придётся добавить.

Лет 10 назад у нас был кластер с нодами по 2 Тб (терабайта) памяти на обычном x86_64 железе. Так что если по другому никак, то даже вертикально есть куда масштабировать

А отвергать микросервисы «просто потому» - это точно такой же бред, как и ввязываться в них не думая.

Я не отвергаю, но ТС просит помощи как получше убедить работодателя/заказчика, а что тут можно сказать, если ничего не известно почему это надо дело, кроме того, что всё устарело и даже роутер dlink?

Но то, что ТС молчит как партизан о профилировке и метриках наводит на мысль, что он и сам не знает и может даже заказчик не настолько дурак, как ему кажется и не спешит шило на мыло менять только потому что оно модное.

Я это воспринимаю как своеобразный крик о помощи. Человек наступил в какашку. Рядом нет даже лужи, чтобы отмыться.

Вот он и эмоционировал на форуме.

Я ему сочувствую. Всё, что думаю про ситуацию, сказал в самом начале: если есть кредиты и нет другой работы - стиснуть зубы и терпеть.

Если есть возможность найти другую работу - валить не разумывая.

и даже роутер dlink

мы десять лет назад в стойки вполне себе ставили коммутаторы dlink и никаких проблем не знали - вполне себе со своими обязанностями справлялись - не зависали, ну не каталисты же за сотни нефти ставить, тем более если мы этим хозяйством управлять не собирались совершенно. А «роутер dlink» в этом контексте звучит примерно как «кто-то на совке купил SOHO-маршрутизатор с WiFi и возможностью залить стороннюю прошивку» и вот они такие обслуживают наш бедный несчастный кластер - звучит как совершенный бред, ровно как и про узлы по 16 тыщ процессов perl.

теории про нормальные формы - это откровенный бред сивой кобылы: нам как разработчикам (да и бизнесу) куда интереснее, чтобы оно работало быстро, а не чтобы было «по науке»

Теории не бред, их надо знать и уметь применять. Но применять с умом, понимая зачем и почему, а не потому что так по фен-шую, если не нужно, то и не применять

Всё это время, на твою голову будут сыпаться проклятия

скажи мне, друг, а зачем ты позволяешь хоть 1 проклятью к тебе прилететь, тем более всем последующим? ты куколд?

Мне например никто ничего подобного никогда не говорит, а если и говорит, то только 1 раз, после чего я ему намекаю, что ща подойду и шею сломаю.

Представь себе мир, где все так будут делать. Ну, или хотя бы ты сам.

Если есть возможность найти другую работу - валить не разумывая.

боюсь тут будут определенные проблемы с этим. В современных реалиях даже чтобы ассенизатором пойти работать нужно какого-никакого царя в голове таки иметь, там оборудование вполне себе дорогое, простои - это прямые убытки и пр. А тут же: у вас архитектура говно и отстала на 15 лет.