По-умолчанию vm.overcommit_ratio равно 50, т.е. процессы не смогут занять (именно реально физически занять) больше 50% памяти.
Случалось что oom killer прибивал процессы когда памяти еще была половина свободна.
Установка vm.overcommit_ratio=100 в /etc/sysctl.conf решает проблему.
Но конечно слепо повторять не стоит, надо четко понимать свой сценарий использования. Кому-то возможно и 300% задать, а кому-то нужно наоборот полностью отключать эту фичу, чтоб использовать можно было ровно столько сколько есть, безо всякого "оверселлинга"... Типа как на vps продают клиентам больше ядер, чем физически есть на сервере с расчетом на то что всем сразу все их ядра не понадобятся. Или как банки схлопываются если вдруг много клиентов резко решат забрать свои деньги (которых уже столько нету).
Про которое новое речь не понял... цитата из фильма про начало 90х.
Есть еще из того же поколения :]
Мораль №3
И кстати со списаниями от мтс за то что не пользуюсь также столкнулся. Ну не пользуюсь... есть телеграмы и т.п., мобильная связь только чтоб смс коды подтверждений получать. И за это они меня на счетчик поставить удумали. Пришлось раскошелиться отправить смс впервые за много месяцев.
Однажды их постигнет участь стационарных домашних телефонов и пленочных фотоаппаратов.
Интересна точка зрения налоговой по этому вопросу :]
Ну и про юридическую часть ни слова.
https://habr.com/ru/articles/781196/
Хостинг‑провайдеры теперь должны уведомлять Роскомнадзор о ведении деятельности с последующим включением в соответствующий реестр, проводить идентификацию пользователей, а также обеспечить взаимодействие с уполномоченными государственными органами по вопросам оперативно‑розыскных мероприятий (СОРМ) и выполнить подключение к государственной системе обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА).
Да что уж там сдерживаться, пора уже и все остальные 2.4/5ггц wifi точки тоже регистрировать.
Собирать данные паспорта всех клиентов этих точек.
Обязать в каждой квартире ставить аппараты для хранения всего траффика за год и чтоб был отдельный интернет канал прямо в фсб. А то вдруг господа изволят просмотреть, а у вас интернет канал забит другими ничтожными задачками.
Очень важное качество когда работаешь в linux под root и запускаешь всякие rm из интернетов :)
От себя добавлю chattr +i (и -i соотвт) - блокирует изменения файлов/папок вообще для всех. Даже root не сможет. Частенько пользуюсь когда нужно железно зафиксировать какие-то мои изменения.
Тинькофф против спама - это как пчелы против меда.
Совершил однажды ошибку, оставив заявку на открытие карты тут. В ответ было стандартное: ах вы из Крыма - ничего не выйдет или приезжайте сами на белую землю. Ну нет и нет, ладно. Однако потом бесконечные звонки и смс с предложенями... того что все равно не смогут выполнить.
Вторая большая ошибка была использовать основной свой телефон при регистрации ИП. Тонны спама от всевозможных банков. И от тинькофф в том числе.
Нужно иметь 2 номера. И тот что приходится "засвечивать" просто держать выключенным и включать только когда это будет нужно мне. А все остальное время - все идут лесом.
На основном номере тем более все идут лесом, кто не в контактах.
Уже не так радужно получается?... Да, можно навернуть --iodepth и получить выше результат, но опять же надо осознавать какое это имеет отношение к реальности.
Но конечно это все синтетические тесты. А можно взять что-то более приближенное к реальному использованию. Например выдрать кусок бенчмарка из bitrix:
Если коротко: он создает 100шт php файлов размером 3кб, делает include (т.е. считывает и запускает) и следом удаляет. Результат они заявляют как "файловых операций в секунду", но конечно это не так. Но всеж мы получим некие "попугаи", хоть немного приближенные к реальности. Когда в процессе выполнения php скрипта в него include'ится еще сотня других - вполне реальная картина. В реальном использовании конечно скрипты эти остаются на месте, а не удаляются как в нашем случае и откладываются в файловом кэше и в opcache php. Но мы же пытаемся именно работу с диском измерить. Вот и получаем этим скриптом более-менее повторяемый результат. Именно считывания с диска кучи мелких файлов. И именно как это обычно и происходит в php скриптах - последовательный include разных небольших файлов.
А иначе все те хитрые замеры большими блоками и большой глубиной очереди конечно показать могут много гб/сек, но сайт как тормозил так и дальше тормозит... Лучше уж вместо диска обращать больше внимания на каком именно процессоре это все работает.
Дизлайк озону.
До тех пор пока:
И пока будет продолжаться бомбежка мусорного спама в "скидках и акциях", от которого отписаться невозможно.
Доводилось сталкиваться с overcommit'ом памяти.
По-умолчанию vm.overcommit_ratio равно 50, т.е. процессы не смогут занять (именно реально физически занять) больше 50% памяти.
Случалось что oom killer прибивал процессы когда памяти еще была половина свободна.
Установка vm.overcommit_ratio=100 в /etc/sysctl.conf решает проблему.
Но конечно слепо повторять не стоит, надо четко понимать свой сценарий использования. Кому-то возможно и 300% задать, а кому-то нужно наоборот полностью отключать эту фичу, чтоб использовать можно было ровно столько сколько есть, безо всякого "оверселлинга"... Типа как на vps продают клиентам больше ядер, чем физически есть на сервере с расчетом на то что всем сразу все их ядра не понадобятся. Или как банки схлопываются если вдруг много клиентов резко решат забрать свои деньги (которых уже столько нету).
А как предпологалось смотреть то самое интервью в заблокированном твиттере без портала в ад?
ну уж нет... слишком поздно править.
я уже фотку подготовил
Нам нужен vpn чтобы создать vpn
Главный вопрос: это баг или фича?...
тоже самое хотел написать.
хорошо что опередили и приняли удар дизлайков на себя :]
Про которое новое речь не понял... цитата из фильма про начало 90х.
Есть еще из того же поколения :]
Мораль №3
И кстати со списаниями от мтс за то что не пользуюсь также столкнулся. Ну не пользуюсь... есть телеграмы и т.п., мобильная связь только чтоб смс коды подтверждений получать. И за это они меня на счетчик поставить удумали. Пришлось раскошелиться отправить смс впервые за много месяцев.
Однажды их постигнет участь стационарных домашних телефонов и пленочных фотоаппаратов.
Интересна точка зрения налоговой по этому вопросу :]
Ну и про юридическую часть ни слова.
https://habr.com/ru/articles/781196/
Хостинг‑провайдеры теперь должны уведомлять Роскомнадзор о ведении деятельности с последующим включением в соответствующий реестр, проводить идентификацию пользователей, а также обеспечить взаимодействие с уполномоченными государственными органами по вопросам оперативно‑розыскных мероприятий (СОРМ) и выполнить подключение к государственной системе обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА).
Мораль №2
Это отсылка была сюда:
https://habr.com/ru/companies/ruvds/articles/781568/
Следующий шаг - а пущай еще все владельцы сайтов хранят весь свой траффик (за свой счет естественно).
А потом и до wifi точек доберутся.
Да что уж там сдерживаться, пора уже и все остальные 2.4/5ггц wifi точки тоже регистрировать.
Собирать данные паспорта всех клиентов этих точек.
Обязать в каждой квартире ставить аппараты для хранения всего траффика за год и чтоб был отдельный интернет канал прямо в фсб. А то вдруг господа изволят просмотреть, а у вас интернет канал забит другими ничтожными задачками.
Зачем спрашивается?...
У меня единственное устройство на 2.4 - робот пылесос. До его появления 2.4 был отключен вообще.
Это как продолжать делать устройства с micro-usb вместо type-c
А как же подтверждение операции по смс? :]
Бывает даже зная пароль не можешь ничего сделать из-за этого т.к. мобильной связи нет например.
В - внимательность.
Очень важное качество когда работаешь в linux под root и запускаешь всякие rm из интернетов :)
От себя добавлю chattr +i (и -i соотвт) - блокирует изменения файлов/папок вообще для всех. Даже root не сможет. Частенько пользуюсь когда нужно железно зафиксировать какие-то мои изменения.
Тинькофф против спама - это как пчелы против меда.
Совершил однажды ошибку, оставив заявку на открытие карты тут. В ответ было стандартное: ах вы из Крыма - ничего не выйдет или приезжайте сами на белую землю. Ну нет и нет, ладно. Однако потом бесконечные звонки и смс с предложенями... того что все равно не смогут выполнить.
Вторая большая ошибка была использовать основной свой телефон при регистрации ИП. Тонны спама от всевозможных банков. И от тинькофф в том числе.
Нужно иметь 2 номера. И тот что приходится "засвечивать" просто держать выключенным и включать только когда это будет нужно мне. А все остальное время - все идут лесом.
На основном номере тем более все идут лесом, кто не в контактах.
Не могу пройти мимо, не приспустив с автора и читателей розовые очки...
Что за скорость мы тут проверим? Ответ - буфферизированную скорость записи. А вовсе не "скорость диска".
Причем кэширование минимум на 2х уровнях - на диске (возможно raid контроллере) и на ОС.
Очевидно, что 100мб влетят в дисковый кэш debian'а даже если у нас лишь 512мб памяти.
<!--... потерто ...//-->
Т.к. получалась слишком уж большая простыня, то проще сделать отсылку на первую нагугленную статью:
https://habr.com/ru/articles/154235/
Лучше уж использовать fio утилиту, где можно точно подстроить много параметров.
Например аналог вышеуказанной dd будет:
fio --ioengine=libaio --direct=1 --buffered=1 --name=test --size=100m --bs=1m --iodepth=1 --readwrite=write
Но много ли обычно на сайтах файлов размером около 1мб? вот и сменим --bs на 4k и вместо записи укажем случайное чтение.
fio --ioengine=libaio --direct=1 --buffered=1 --name=test --size=100m --bs=4k --iodepth=1 --readwrite=randread
Уже не так радужно получается?... Да, можно навернуть --iodepth и получить выше результат, но опять же надо осознавать какое это имеет отношение к реальности.
Но конечно это все синтетические тесты. А можно взять что-то более приближенное к реальному использованию. Например выдрать кусок бенчмарка из bitrix:
Если коротко: он создает 100шт php файлов размером 3кб, делает include (т.е. считывает и запускает) и следом удаляет. Результат они заявляют как "файловых операций в секунду", но конечно это не так. Но всеж мы получим некие "попугаи", хоть немного приближенные к реальности. Когда в процессе выполнения php скрипта в него include'ится еще сотня других - вполне реальная картина. В реальном использовании конечно скрипты эти остаются на месте, а не удаляются как в нашем случае и откладываются в файловом кэше и в opcache php. Но мы же пытаемся именно работу с диском измерить. Вот и получаем этим скриптом более-менее повторяемый результат. Именно считывания с диска кучи мелких файлов. И именно как это обычно и происходит в php скриптах - последовательный include разных небольших файлов.
А иначе все те хитрые замеры большими блоками и большой глубиной очереди конечно показать могут много гб/сек, но сайт как тормозил так и дальше тормозит... Лучше уж вместо диска обращать больше внимания на каком именно процессоре это все работает.
когда это все происходит где-то внутри gmail, то может и ладно...
но на своем сервере лучше бы сразу обрывалось соединение на попытку отправить несуществующему ящику
и как нам в этом случае уничтожить user+tinkoff@ ?
идея ж не в том чтоб создать, а в том чтоб потом его прибить