LINUX.ORG.RU

Ответ на: комментарий от bodqhrohro_promo

Очевидно же — надо пропатчить эти процессы, чтобы они согласовывали выделение ресурсов.

Ну-ка, расскажи мне, как это возможно с учетом виртуальной памяти и overcommit'а. Ещё было бы безумно круто увидеть стратегии согласовывания памяти, а то я плохо понимаю, что в таком случае делать условному постгресу. Отказываться выполнять запросы? А чем это лучше?

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

Память нужна вся, целиком. Малонужных деталей на двадцать мегабайт. Что делать?

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

что в таком случае делать условному постгресу

А в том и суть, что надо по ситуации смотреть, а не валить всё на бедную СУБД. Особенно печально при использовании ORM, СУБД даже косвенно сложно понять, что на самом деле от неё хотят.

Что делать?

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

bodqhrohro_promo
()
Ответ на: комментарий от Iron_Bug

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

leave ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

А в том и суть, что надо по ситуации смотреть, а не валить всё на бедную СУБД. Особенно печально при использовании ORM, СУБД даже косвенно сложно понять, что на самом деле от неё хотят.

Пажжи. Ещё раз — как приложению определять, что доступной памяти мало? И что ему с этим знанием делать?

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

И сидеть на ресурсах, которые не используются? Мы же разоримся.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

как приложению определять, что доступной памяти мало

Тебе free -m забанили? И при чём тут это в данном контексте, если ресурсы должны закладываться при проектировании и таких ситуаций возникать не должно?

сидеть на ресурсах

Не сидеть, а арендовать их по времени у облачников. А если на всём своём сидите — надо закладывать запас прочности, щитоподелать, это одно из золотых правил инженера. Безлимиты существуют только в головах шизиков-халявщиков, на деле у всего есть проектная мощность: например, 15000 запросов в день, а выше — идите нафиг или переходите на пакет пожирнее, и даже не упрашивайте. Можно, конечно, оверселлингом заниматься, но это ССЗБизм и оправданию не подлежит.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Тебе free -m забанили? И при чём тут это в данном контексте, если ресурсы должны закладываться при проектировании и таких ситуаций возникать не должно?

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

Не сидеть, а арендовать их по времени у облачников.

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

заложенное потребление памяти может превышать доступную память в разы

Значит, оно на самом деле не заложенное, не лукавь. Заложили == обеспечили. Иначе получается как у персонажа с аватарки cheetah111v — «и та-а-а-ак сойдёт».

настолько повысишь стоимость, что все охренеют

Ну то есть ты расписываешься за нищеговно, ясно. Оно имеет право иметь место, но неча им бравировать.

Ну ты в курсе

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

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Значит, оно на самом деле не заложенное, не лукавь. Заложили == обеспечили. Иначе получается как у персонажа с аватарки cheetah111v — «и та-а-а-ак сойдёт».

Слова thin provisioning тебе о чем-нибудь говорят?

Ну то есть ты расписываешься за нищеговно, ясно. Оно имеет право иметь место, но неча им бравировать.

Facebook — нищеговно?

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

Я не о том.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

thin provisioning

Вышеупомянутый оверселлинг.

Facebook — нищеговно?

Именно — король чуханов, победоносно несущий «интернет» в чуркестаны второго, третьего и последующих миллиардов. Тарифы с более дешёвым или вообще бесплатным трафиком к сосальным сетям суть огромная и неиллюзорная угроза сетевому нейтралитету, а не та фигня, которую пиндосы хайпят с 2015-го.

Я не о том

Это тебе пример doing right. Полностью так расходы на запас прочности, конечно, не перекрыть, ибо мало кому надо такая ненадёжная фигня, но хоть что-то. А на оставшихся ресурсах можно крипту майнить, например :D Крипта разная есть, не только вычислительные ресурсы задействующая, но и дисковое хранилище, например.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Ты так говоришь, будто СШП не в умеренных широтах

Я не знаю, что ты имеешь ввиду под умеренными широтами, но в США -30 бывает регулярно только на Аляске и ещё в паре штатов, на которые всем наплевать. Климат от широт не то чтобы прямо напрямую зависит.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

Вот ещё и при том, что сервер выполняет несколько ролей в т.ч. ради экономии денег.

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

leave ★★★★★
()
Ответ на: комментарий от hateyoufeel

-30

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

bodqhrohro_promo
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Именно — король чуханов

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

madcore ★★★★★
()
Ответ на: комментарий от madcore

слово «приходится» какое-то нехорошее. всё равно что сказать «иногда приходится кушать говно». ну, приходится - так приходится. но можно подумать о других вариантах :)

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Всё это хорошо работает для академических теоретиков и писателей 64К-демок из 90-х.
Простой пример костыля: есть некий обработчик загружаемых изображений. При не очень хорошем раскладе он может сожрать гиг, может и четыре. А может и шестнадцать, и при этом корректно отработать, но редко. Сколько будет - заранее неведомо, каждый процесс многократно выделяет/освобождает память. Влезть в код возможности нет. Могу построить очередь с лимитом процессов исходя из наихудших предположений. Но это случается очень редко, поэтому эффективнее использовать среднюю оценку потребления и изредка перезапускать убитый оом-процесс придержав очередь.

madcore ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Ты что, софт на Java никогда не видела?

hateyoufeel ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Вышеупомянутый оверселлинг.

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

Именно — король чуханов, победоносно несущий «интернет» в чуркестаны второго, третьего и последующих миллиардов. Тарифы с более дешёвым или вообще бесплатным трафиком к сосальным сетям суть огромная и неиллюзорная угроза сетевому нейтралитету, а не та фигня, которую пиндосы хайпят с 2015-го.

Чиво? Я правильно понимаю, что ты называешь нищебродами компанию с 10 миллиардами чистой прибыли в год?

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

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

Ты почему-то никак не хочешь обратить внимание на пример. А он прост: есть много хорошо написанных приложений, которые друг о друге не знают. Но они потребляют много памяти в силу специфики работы. Как бороться с OOM не увеличивая стоимость проекта в пять раз?

kirk_johnson ★☆
()
Ответ на: комментарий от hateyoufeel

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от kirk_johnson

ты спрашиваешь, как сидеть на трёх стульях? ответ: никак. ну либо урезать лимиты тем самым приложениям. «десять, но маленьких» (С)

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

ты спрашиваешь, как сидеть на трёх стульях?

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

ответ: никак.

То есть нам все-таки придется иметь дело с возможным OOM?

ну либо урезать лимиты тем самым приложениям. «десять, но маленьких» (С)

Как?

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

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

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

Как?

как угодно. от урезания лимитов на юзеров до загона в виртуалки.

Iron_Bug ★★★★★
()
Ответ на: комментарий от kirk_johnson

но это самая распространенная практика

Миллионы мух не могут ошибаться!

бабло не резиновое

Закон Мура тоже, равно как и пузырь зарплат в IT.

Я правильно понимаю, что ты называешь нищебродами компанию с 10 миллиардами чистой прибыли в год?

С миру по нитке — бедному рубашка.

bodqhrohro_promo
()
Ответ на: комментарий от madcore

При не очень хорошем раскладе он может сожрать гиг, может и четыре

У меня так сайт умер (не шучу). Точнее, он в коме уже пару месяцев.

bodqhrohro_promo
()
Ответ на: комментарий от Iron_Bug

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

Лол. То есть ты готова потратить на проект в пять раз больше только потому, что тебе лень настроить OOM-killer, который нужен раз в полгода?

как угодно. от урезания лимитов на юзеров до загона в виртуалки.

И что изменится в первом и втором случае?

kirk_johnson ★☆
()
Ответ на: комментарий от bodqhrohro_promo

Миллионы мух не могут ошибаться!

Конторы, которые не швыряются попусту баблом, остаются на плаву. Ну не знаю, звучит разумно. Ты так не считаешь?

Закон Мура тоже, равно как и пузырь зарплат в IT.

И чо?

С миру по нитке — бедному рубашка.

И чо?

kirk_johnson ★☆
()
Ответ на: комментарий от Myau

Звуковое сопровождение

Неплохое аниме. С душой рисовали.

EXL ★★★★★
()
Ответ на: комментарий от Iron_Bug

видеть - видела. но не в продакшне

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

попусту

Не попусту, а в предотвращение технического долга, который всё равно придётся устранять.

И чо?

И то, Чебурашечка, что наращивание костылей, абстракций и говнокода — это не золотая пуля. К финишу приходит не тот бегун, что бежал со всех ног и выдохся на полдороги, но тот, что здраво оценивает силы.

И чо?

То, что они такие же «богачи», как Мавроди или российские чиновники — надурили честной народ и рады, а народ хавает и добавки просит. И это не те победители, которых не судят.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Не попусту, а в предотвращение технического долга, который всё равно придётся устранять.

Не факт, что придется. Об этом-то и разговор.

И то, Чебурашечка, что наращивание костылей, абстракций и говнокода — это не золотая пуля. К финишу приходит не тот бегун, что бежал со всех ног и выдохся на полдороги, но тот, что здраво оценивает силы.

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

То, что они такие же «богачи», как Мавроди или российские чиновники — надурили честной народ и рады, а народ хавает и добавки просит. И это не те победители, которых не судят.

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Не факт, что придется

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

он жрет память в силу каких-то валидных причин

Я ещё раз повторяю — надо под эти валидные причины закладывать ресурсы и управление ресурсами, иначе ССЗБ. OOM существует и имеет такую дурную славу именно потому, что ядро понятия не имеет, чего вдруг процесс так обожрался. Для пожирания процессора хотя бы приоритеты есть, а для памяти до сих пор не было, и это очень большой шаг вперёд, ящитаю.

проблему можно решить правильно настроив OOM

https://orig00.deviantart.net/2f3d/f/2016/216/3/6/twilight_fixes_friendship_p...

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

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

Так, отлично, а конкуренты тут причем?

Я ещё раз повторяю — надо под эти валидные причины закладывать ресурсы и управление ресурсами, иначе ССЗБ. OOM существует и имеет такую дурную славу именно потому, что ядро понятия не имеет, чего вдруг процесс так обожрался. Для пожирания процессора хотя бы приоритеты есть, а для памяти до сих пор не было, и это очень большой шаг вперёд, ящитаю.

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

https://orig00.deviantart.net/2f3d/f/2016/216/3/6/twilight_fixes_friendship_p...

А?

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

а конкуренты тут причем?

Дык на то они и конкуренты.

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

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

А?

Метафора.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Дык на то они и конкуренты.

И чо?

Так проблема та же: он не знает, какой процесс важнее.

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

И то, что кого-то приходится убивать, само по себе проблема.

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

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

И чо?

Чтобы с ними конкурировать.

который подобные процессы ищет лучше

Но подход тот же — эвристика, иже гадание на кофейной гуще. Это не инженерный подход.

когда у тебя несколько миллионов серверов

... без автоматизированного и гибкого масштабирования никуда.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Но подход тот же — эвристика, иже гадание на кофейной гуще.

Ты статью от них читал? Там постоянный анализ memory pressure и прочих факторов.

Это не инженерный подход.

Весь TCP построен на гадании на кофейной гуще. И почти вся алгоритмистика построена вокруг среднего случая. Так что нет, вполне себе инженерный.

... без автоматизированного и гибкого масштабирования никуда.

Ну вот они и сделали автоматизированное масштабирование. Но он иногда дает сбои, потому что конфигураций слишком много.

kirk_johnson ★☆
()
Ответ на: комментарий от hateyoufeel

кто «весь этот»? я работала в автоматизации, в телекоме, в сетевых компаниях. никаких жаб в продакшене.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Тот же Сбербанк, о котором ты выше говорила, использует жабу. stevejobs подтвердит.

hateyoufeel ★★★★★
()

Ура, новая команда! На 5 букв в хакерском словарном запасе больше.

Valman_old
()
Ответ на: комментарий от hateyoufeel

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

на крестах написаны легаси системы. Новые платформы - ППРБ, машинленинг на хадупе - на жабе/скале стопроцентно, для машиншелинга иногда питон

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

Iron_Bug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.