- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
День добрый,
Для большинства завсегдатых SE в моих словах не прозвучит ничего нового, я буду говорить о погрешностях пользователей который в итоге могут привести к проблемам и у самого хостера.
Недавно работая с клиентом по одному вопросу, был вынужден мониторить его процессы и обратил внимание на то, что очень регулярно всплывал процесс lynx поднятый из крон заданий, посмотрел и ужаснулся, но сперва не стал ничего говорить клиенту, что бы задать ему вопрос по этому поводу и проверить теорию о том, что он просто не разобравшись вставил задание в крон. И я задал вопрос, но позже...
Анализ:
Я процитирую только временную форму из крона, там банальное дергается lynx на его же сайт, который видимо что-то шевелит в его сайте:
1.
* * */1 * *
* */3 * * *
2.
*/59 * * * *
*/55 * * * *
*/50 * * * *
*/45 * * * *
3.
*/25 * * * *
*/19 * * * *
*/17 * * * *
*/13 * * * *
Я условно разбил их на три секции , что бы поговорить о каждой отдельно:
Первая секция:
Итак , самая первая запись "* * */1 * *" является самой интересной и бессмысленной, она трактует выполнение указанного задания "каждую минуту, каждого часа, каждого 1го (одного, а не первого(интервал)) дня, каждого месяца каждого года", фактически она ни чем не отличается от формулировки "* * * * *". И выполняется 60*24 раз в сутки.
Вторая запись чуть проще, выполнение происходит "каждую минуту каждого третьего часа, каждого дня месяца года", то есть происходит 24/3*60 запусков в сутки.
Вторая секция:
Слеш в кроне означает интервал который будет выдерживать крон, по этому указание цифр не делящих 60 без остатка (в случае минут) и 24 в случае часов.... является почти полностью бессмысленным (третья секция имеет небольшое исключение). Почему?
Давайте посмотрим на запись */59, она трактуется как "каждую 59ю минуту", простите меня, в часу может быть 2 раза 59я минута? НЕТ ! По этому вместо */59 правильно было бы написать просто 59, она и так 1 раз !!!! С точки зрения выполнения , думаю что крону пофик ) но запись выглядит безграмотно, показывает отсутствие понимания работы крона.
Третья секция:
Как видим, ни одно из чисел не делит 60 без остатка... это говорит о том же непонимании... Почему?
*/25, трактуем как "каждую 25ю минуту", соответственно, выполнений в часу может быть всего 2, а именно на 25й минуте и на 50й минуте этого часа.... следом будет простой до следующей 25й минуты следующего часа, а это уже интервал 35 минут :D
*/13, трактуем как "каждую 13ю минуту", соответственно.......... 13я минута, 26я, 39, 52, следом ждем до 13й минуты, интервал = 21 минута :D
Если вам требуется указать несколько запусков крона в неделимом интервале, следует использовать конструкцию:
1,13,27,55 * * * *
Это будет означать что будет происходить 4 запуска в каждом часу, на 1й , 13й, 27й и 55й минутах !!!!!
Получив ответ от клиента на вопрос "как должны по его мнению запускаться эти cronjobs" я получил ответ полностью подтверждающий описанное выше, он сказал что самый первый описанный мною крон, должен был запускаться 1 раз в сутки :D А по факту запускался 24*60 раз в сутки. :) Но последующее было куда круче, он сказал что они ВСЕ должны запускаться всего 2 раза в сутки :) Все задания :D А положенное в крон он взял из документаций по движку (не проверял)
Итого: 10 кронов описанных выше * 2 раза в сутки = 20 запусков в сутки, я не поленился и посчитал сколько описанные выше кроны делали запусков, что же товарищи, держите: 2,304 запусков за сутки!
Я думаю будет излишним пояснять разницу между 20 и 2,304 запусками :D Пусть нагрузка от крона не супер большая, но она возросла в 115,2 раза по сравнению с требуемым, ввиду некорректной настройки.
Теперь как говорится мораль:
Во первых, при неправильной настройке cron вы можете получать не правильную работу вашего приложения, а во вторых создавать чрезмерную нагрузку на собственные мощности даже не подозревая этого :D
Рекомендации:
Делаем выводы читатели, читаем как работает cron :)
С Уважением,
Romka_Kharkov, типичные ошибки тех, кто не читал man crontab
Romka_Kharkov, типичные ошибки тех, кто не читал man crontab
Согласен с вами, я же написал что для завсегдатых это не новость, я просто привел кое какие цифры, что бы дать понять читателям на сколько можно ошибиться... это даже не в 1 или 2 раза , тут > Чем в 100 раз :D Ну и хостеров может быть лишний раз "призвать" посмотреть в кронтабы клиентов ))) гляди нагрузки чуток отпадет само собой :D
Роман, спасибо вам за интересное описание и наглядные примеры. Полезно и познавательно!
что бы не положить хостера, нужно задавать юзерам лимиты.
сколько раз уже слышал чтото типа: отпусти лимиты этому юзеру!! это наш топовый клиент!
и через 15 минут: почему все тормозит! настрой все.
а так - полезно чо.
что бы не положить хостера, нужно задавать юзерам лимиты.
сколько раз уже слышал чтото типа: отпусти лимиты этому юзеру!! это наш топовый клиент!
и через 15 минут: почему все тормозит! настрой все.
а так - полезно чо.
Ух ты, лимиты на крон задания? любопытно, подробнее пожалуйста.... :)
nice на процессы юзера, /etc/security/limits.conf итд, но современный мир, так привязанный к isp manager конечно же не решит это.
я тут столкнулся с подобной проблемой:
нескольким важным юзерам нужен перл, сам интерпритатор и, естественно ими нужен ssh.
кривой скрипт-перл, помещенный так же в крон сиииильно присадил сервер.
запрещать юзерам перл - не вариант. был бы вызван скрипт из httpd - сработали бы лимиты веб-севрера. /etc/security/limits.conf решил проблемы сразу из коробки, ну и + еще одна педалька
Cloudlinux?
nice на процессы юзера, /etc/security/limits.conf итд, но современный мир, так привязанный к isp manager конечно же не решит это.
я тут столкнулся с подобной проблемой:
нескольким важным юзерам нужен перл, сам интерпритатор и, естественно ими нужен ssh.
кривой скрипт-перл, помещенный так же в крон сиииильно присадил сервер.
запрещать юзерам перл - не вариант. был бы вызван скрипт из httpd - сработали бы лимиты веб-севрера. /etc/security/limits.conf решил проблемы сразу из коробки, ну и + еще одна педалька
Процесс от юзера работает? Можно чекать и килять + блок юзера + репорт ему.
Например небольшой набросок на php
Ух ты, лимиты на крон задания? любопытно, подробнее пожалуйста.... :)
Как уже писали, pam_limits некоторые может поставить.
nice на процессы юзера, /etc/security/limits.conf итд, но современный мир, так привязанный к isp manager конечно же не решит это.
я тут столкнулся с подобной проблемой:
нескольким важным юзерам нужен перл, сам интерпритатор и, естественно ими нужен ssh.
кривой скрипт-перл, помещенный так же в крон сиииильно присадил сервер.
запрещать юзерам перл - не вариант. был бы вызван скрипт из httpd - сработали бы лимиты веб-севрера. /etc/security/limits.conf решил проблемы сразу из коробки, ну и + еще одна педалька
cronrun в манагере с некоторых времён лимиты умеет ставить.
Ну или более универсальный вариант, cgrulesengd умеет во время смены euid/egid запиливать процесс в нужную группу, а там уже можно прикрутить blkio,cpu,memory. Это более универсальный вариант, нежели pam.
И, если мне не изменяет память, то memory считает rss, а не virt как rlimit.
Как уже писали, pam_limits некоторые может поставить.
На сколько я понимаю, они ни коем образом не предотвращают ничего :D