Replies (9)

  • @fillest, есть slabinfo, есть zoneinfo. Можно ещё, наверно, в perf'е как-нибудь выловить.
  • @oxpa, к zoneinfo не вижу доков, но вроде можно в других местах найти описания полей, и видимо надо почитать про zone watermarks..
    Но это всё вроде текущие снапшоты, а не каунтеры, т.е. то же семплирование, в итоге. Лан, пасиба, всё равно можно будет покопать ещё в этом направлении
  • @fillest, zoneinfo это не то, конечно. Посмотри на perf. Это и есть сэмплирующий профилировщик.
  • @oxpa, ну нужно не семплирование, т.к. между семплами может происходить куча аллокаций ещё. Т.е. например, идёт деплой, на одной секунде схавано 500мб, а на следущей 900мб. А между ними мог быть ещё бОльший пик. Можно конечно сильно увеличить частоту семплирования, но это оверхед. Если бы где-то трекался max или постоянный каунтер, можно было бы бесплатно посчитать за любой период. Хотя нужен специфичный max, не учитывающий, скажем, page cache, вряд ли тако есть.. Но, я просто думаю, вот например oom killer ведь как-то триггерится по каким-то числам, хотя может и просто по эвентам, конечно. Сваппер вон походу просто по таймеру анилизирует эти zone watermarks
  • @fillest, Вообще, исходная задача — подобрать верх памяти для кучки виртуалок для локальной разработки :) Их несколько, а память не очень резиновая у людей на хостах (но скорее всего придётся надавить чтоб им докупили просто памяти, конечно). Задача довольно дебильная, чтоб городить рокетсаенс для неё, но мне просто стало интересно
  • @fillest, о-о-о, брат, та ты уже начал велосипедить. Просто посмотри в мониторинге usr использование и ориентируйся по нему. Хоть с 5 минутным интервалом. Один фиг памяти станет мало и придётся докупать. Знать точный максимум не нужно.
  • @oxpa, ещё не начал, но в голове нимношк да :)

    ну для серваков бы пригодилось тоже, кстати, чтоб обнаруживать нехватку заранее, а не по могилкам от оом-киллера или свап-тормозам
  • @fillest, ты рискуешь попасть в ситуацию, когда программисты лепят любую херню и запускают в продакшен =) Используй мониторинг + сбор логов (чтобы быть первым, кто узнает про oom).
    Я тут смотрел как пилят небольшую rtb: в продакшене любые гигабайты, но все тесты на 1 процессоре и паре гигов памяти. Иначе это разросталось во что-то невероятное.
    И это, своп не нужен -__-
  • @oxpa, лепят любую херню и запускают в продакшенэто_норма.жпг, всё под это и дизайнится, по возможности; это для меня уже аксиома навроде "сетка будет фейлить".
    Причины причём могут быть разные, вроде банального давления менеджеров, отвлечений и т.д., проще под это затачиваться, чем вводить бюрократические процедуры, которые всё равно будут фейлить и добавлять кучу мозгоебли и замедления при этом для всех.
    Мы вообще щас частенько сначала просто катим на одну из тачек сразу — вчера вон тачка повисла нахуй просто наглухо из-за оом (так, что даже зассшиться было нельзя — с плотным дрочевом диска — своп-то отключен, но видимо хуй там он до конца отключается на практике, кстати, уже замечал), ну и ладно какбе, новый трафон в это вреям пошёл на остальные, там предусмотрен уже запас капасити, автоскейл и т.д. Это из той же серии что techblog.netflix.com
    С перформансом то же самое — не хватает ресурса лабораторно бенчить-тестить месяцами, вместо этого просто вымазал специальным постоянно работающим профайлером (и кучкой мониторинга, да) прямо продакшен, и всё. Вижу ретроспективно аномалию — иду смотю в лог — вижу причину. На моделирование многих реальных случаев заранее — даже не знаю скока времени бы ушло, сама оценка займёт кучу времени.