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

DB2 блокировочник по своей природе, по крайней мере таким был 8 лет назад, более того, у него еще была забавная фича - «эскалация блокировок», когда оно принимало решение заблокировать всю таблицу.

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

По играм хорошо видно, что отличаются. Типичная французская игра - коридор с красивыми обоями.

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

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

Подразумеваются сложные запросы ессно а не просто table scan.

Чтобы быть профессионалов нужно многое знать.

Например если программист не знает основ устройства MSSQL https://learn.microsoft.com/ru-ru/sql/relational-databases/indexes/heaps-tables-without-clustered-indexes?view=sql-server-ver17
https://learn.microsoft.com/ru-ru/sql/relational-databases/sql-server-guides?view=sql-server-ver17 Внутренние и архитектуры SQL Server руководства по архитектуре
то таковые скорее «шаманят с бубном», а не программируют.

700 ГБ оперативной памяти

Мало, надо еще 800 Гб хотя бы, тогда может даже CS 1.6 сервак сможешь поднять

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

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

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

Ткнуть тебе явно в другую работу.

при этом постоянно приходят ко мне же с проблемами почему их 700-та гиговые виртуалки тупят и падают.

кста, узнаем почему?

Подразумеваются сложные запросы ессно а не просто table scan.

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

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

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

Но к сожалению, такая простота в жизни встречается редко.

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

ага, подтаскивает цнц всех команд полушария )

Да ТС их злобно ребутает «патамушта» оно без докеров.

Да ТС их злобно ребутает «патамушта» оно без докеров.

А чо в логи или в очко глянуть неварик? )

Так ТС молчит. Может, заткнул?)

эээ… а при чём тут вообще мелкософтовская база?

Лишь для примера приведена.

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

DB2 блокировочник по своей природе, по крайней мере таким был 8 лет назад,

Сейчас тоже блокировочник, но многое улучшили.

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

LOCKSIZE (ROW / PAGE / TABLE / ANY) — гранулярность блокировок;

LOCKLIST — общий пул для блокировок;

MAXLOCKS — процент пула, доступный одной транзакции;

LOCKESCALATION — стратегия эскалации.

так никто и не накладывал. просто под онтопиком оно неактуально.

вообще, в мире лидирующее место среди БД занимает Оракл. хотя я не могу сказать о нём ничего хорошего, я с ним имела дело и мне это не понравилось (не сама база, а те баги и глюки, которые были в их софте). его догоняет Мускуль (видимо, потому что в любом вебе он есть практически всегда). причём Мускуль наверняка скоро обгонит Оракл, судя по трендам. мелкософтовский сервер только на третьем месте, с большим отставанием от Мускуля, за ним идёт Постргрес, и он догоняет мелкософт, когда-нибудь он его обгонит, потому что база у них весьма неплоха и набирает популярность. дальше идёт Монга и прочие.

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

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

вообще, в мире лидирующее место среди БД занимает Оракл.

Не об этом суждение было.

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

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

так о чём же тогда?

В документации по архитектуре MSSQL много полезной информации о методах использования памяти.
Разрабатываю проект для которого понимание того как оптимально и эффективно управлять памятью в memory и в файлах весьма актуально.
Проще говоря как создать эффективную архитектуру хранения и доступа к данным.

вообще, в мире лидирующее место среди БД занимает Оракл.

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

Лидирующее место среди БД в мире занимает Гугол, а среди СУБД, безусловно SQLite

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

… ээ… а почему про использование памяти надо читать именно там?

Не только там.
В разных проектах встречаются интересные алгоритмы управления памятью.
Мануала в котором собраны все методы управления памятью в memory и в файлах просто нет.

В разных проектах встречаются интересные алгоритмы управления памятью.

вот. на то он и опенсорц, чтобы просвещаться.

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

сформулировать ТЗ чаще сложнее, чем понять, как писать и что писать. если ты чётко и внятно сформулировал задачу, считай, что ты уже на 50% её решил. если не на 80.

сформулировать ТЗ чаще сложнее, чем понять, как писать и что писать. если ты чётко и внятно сформулировал задачу, считай, что ты уже на 50% её решил. если не на 80.

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

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

Ныне в тренде - «Кто выще бье, тот краще грает».

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

Ностальжи.

Когда крупное предприятие приобрело DX на 100Mgz, то все программисты города говорили - «На таком компе весь город можно обрабатывать».

А ныне, …

быстренько подсуетятся и обоснуют, почему железо для этих машин надо купить именно у них :)

У хорошего спеца всегда ругают, так как у таковых всё хорошо работает и они по мнению начальства ничего не делают.
А спецы и проект треда всегда в тренде и начальство «понимает», что без них «всё рухнет».
Это невозможно исправить в принципе, так как дураков победить невозможно.

… обоснуют, почему железо для этих машин надо купить именно у них :)

Пошучу

Это суждение во многом подходит к «развитию» нынешних программных технологий.
Ой, молчу, молчу …

Sorry, всем.
Настроение хорошее.
Шас спою.

«Когда мы были молодыми и чушь прекрасную несли …».

Тогда и задачи были проще. Были ли задачи, например, типа поисковых систем, которые быстро и эффективно должны обойти весь Интернет (175 зеттабайт) и быстро искать в таком объеме?

Было ли тогда потоковое видео, когда в риалтайме надо обрабатывать кучу запросов от пользователей и отдавать видеопоток в 4K с 30/60 кадров в секунду. Были ли тогда глобальные торговые сети, доставка продуктов домой за 15 минут? Заказ и доставка любого товара в любую деревню за считанные часы или дни?

Нет, конечно.

Это как деды, наверное, ворчали: «зачем эти дурацкие вонючие автомобили? хороший конь достаточно быстро скачет и много может увезти»

сформулировать ТЗ чаще сложнее, чем понять, как писать и что писать. если ты чётко и внятно сформулировал задачу, считай, что ты уже на 50% её решил. если не на 80.

Кстати жулики обычно предпочитают работать без фиксированного ТЗ, но с фиксированным размером оплаты за проект?

Полагаю, что коллеги или начальство ТС случайно увидели этот тред. Не так уж много мест, где монолиты на древнем Perl разворачиваются на виртуалках с 700 Мб памяти.

Именно поэтому я, например, молчу о говнопроектах, в которые мне приходилось вступать. Хотя тоже навидался всякого. И, как всегда и везде в жизни, чем менее квалифицирован человек и менее осведомлен о реалиях жизни, тем более он уверен в себе. «Ты что говном назвал? Да нашей версии Perl’а ещё и 40 лет не исполнилось! Да мы используем самый крутой паттерн разработки Big Ball of Mud! Да мы тебе сумасшедшие две миски риса в месяц платим! В два раза больше, чем остальным, нормальным ребятам, которые больше тебя сделали!»

У меня, кстати, подозрение, что это может быть LiveJournal.

• Древний проект - да.
• Написан на Perl, и очень давно - да.
• Использует memcached - да.

С другой стороны, насколько я смутно могу помнить, LiveJournal был одним из пионеров микросервисов, в нём точно вроде часть работы распределялась по разным машинам и сервисам. С другой стороны, всё это было настолько давно, имею в виду популярность ЖЖ, что могу и заблуждаться.

Кстати жулики обычно предпочитают работать без фиксированного ТЗ, но с фиксированным размером оплаты за проект?

Пошучу.

Iron_Bug что в этом спец?

Iron_Bug что в этом спец?

«По телевизору показывают жуликов. Ну чем я хуже?».

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

Это во сколько раз? Ходят легенды про аутсорсеров, продающих джунов по цене милордов, да ещё и с наценкой.

700-гиговая махина останется 700-гиговой махиной и в докере,

Почему? Ведь можно разбить хотя бы на СУБД, приложение и т.п. Раскидать по разным хостам?

но теперь к ней сложнее подключить дебаггер.

Чем сложнее? Perl не умеет в remote debugging? или нет консольных отладчиков типа Vim Spector, etc.

А ну еще это всё находится в датацентре где платят 5000 за юнит (представляете качество услуг?)

А adman.com ещё дешевле, со всеми вытекающими, и не только из цены.

Кто-нибудь вообще смотрел хотя бы atop и iostat?

Или только переписывание и передвижение движимостей между рантаймами спасёт «отца русской демократии»?

При этом не делается вообще ничего, что касается качества и модернизации. И люди не понимают, что они отстали на 10-15 лет от прогресса.

Люди ИМБУРДировали себе спокойно 15 лет, а тут появился ты, и хочешь испортить им кормушку, которая так долго кормила этих бездельников? Думаешь, они будут тебе благодарны? :) Возможно всё это делается для галочки и даже сама эта система даром никому ненужна. Просто очередной распил с корытцем, которое кормит очередную группу присосавшихся к ней?

Решение подобных проблем делается следующим образом.

1. Сбор информации об архитектуре. У вас есть полная диаграмма компонентов архитектуры, представление о том, что каждый компонент делает, а также потоки данных (что, откуда и куда ходит)?
2. Поиск узких мест. Выводите различные метрики потребления CPU, памяти и прочих важных ресурсов с каждого компонента. Смотрите, есть ли возможность что-то где-то убавить или прибавить.
3. Выяснение причин, которые способствовали возникновению каждого конкретного узкого места.
4. Составление плана устранения узких мест в архитектуре: перечня мероприятий, необходимых для улучшения работы текущей конфигурации приложения.
5. Оценка трудозатрат на выполнение каждого пункта плана.
6. Оценка запаса по нагрузке, который может выдержать система при её повышении.
7. Донесение полученного результата до руководства. В нескольких тезисах:

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

Таким образом, уже имеющуюуся архитектуру можно привести в порядок без необходимости обезьянить, разбивания всё на микросервисы (что скорее приведёт к бОльшему потреблению ресурса, который будет скорее простаивать, чем работать).

Ну а дальше уже пусть сам бизнес решает: готов он потратиться на R&D или так и будет эксплуатировать имеющееся решение без внесения серьёзных исправлений. В первом случае вам будет над чем поработать, во втором - лучше валите поскорее, пока эта галера окончательно не потонула.

В целом же эти все очереди, что kafka, что прочие другие MQ, имеют выигрыш в сравнении с БД исключительно за счет того, что там принято забивать на ACID со всех сторон

Кто мешает использовать их в режиме ACID?

ну и, соответственно, тысяча потребителей - тоже много

Много для одной ноды? Берём K8s, деплоим туда многонодовую Кафку, и легко получаем 10K+ соединений? Разве не для этого сделали Strimzi Kafka operator ?

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

Ненужно тут сказки рассказывать, очереди как раз для того и придумали, чтобы создать некий демпфер (инфраструктурный буфер) для больших всплесков входящих данных, с которыми не в состоянии справиться СУБД и старинные приложения.

Очереди - это не «модная игрушка», а современный инструмент для повышения устойчивости систем к всплескам нагрузки.

Volt + Redpanda: 100K complex decisions per second for <$13 an hour

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

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

Что за вера в святой Докер. Типа, если взять кусок дерьма, засунуть в Докер то оно станет пахнуть? Что изменится то? Кроме того, что поддерживать станет еще сложней, так как добавится еще один уровень/инструмент/слой.

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

Кроме того, это может только ухудшить ситуацию,

Насколько микропроцентов в кейсе 700 гиг рамы?

Были ли задачи, например, типа поисковых систем, которые быстро и эффективно должны обойти весь Интернет (175 зеттабайт) и быстро искать в таком объеме?

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

Было ли тогда потоковое видео, когда в риалтайме надо обрабатывать кучу запросов от пользователей и отдавать видеопоток в 4K с 30/60 кадров в секунду.

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

Были ли тогда глобальные торговые сети, доставка продуктов домой за 15 минут? Заказ и доставка любого товара в любую деревню за считанные часы или дни?

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