Проверка повторного запуска скрипта
покажи им man flock(1)
или
на скольки машинах может запускаться?
По условию текущей задачи на одной. И никто не может внятно ответить, зачем может потребоваться на двух.
Меня еще убивают комментарии про мемкеш блокировку типа "это просто и надежно"
Ага, только если приложенька не дай бог будет сдыхать не отпустив лок, замучаетесь эти локи чистить.
Плюс лишняя зависимость на лишнюю систему. Из разряда, а что будет, если мемкеш умер, а мы запустим два инстанса скрипта...
для этого нужен резервный memcached и пара вочдогов к каждому. просто и надёжно!
В общем я понял, что я не один старпер такой ) All hail the code review!
и чтобы скрипт перед запуском стучался к вочдогам и проверял что с енвайронментом все в порядке!
какой смысл давать ссылку на lmgtfy, где надо сразу вводить ответ на вопрос?
и с правами еще может быть попроще, файловые локи требуют, чтобы у приложения были права на запись
> И никто не может внятно ответить, зачем может потребоваться на двух.
как только одной машины перестанет хватать, сразу захочется две
лок мемкэша, по идее, должен быть быстрее, чем файловый локtmpfs
как только одной машины перестанет хватать, сразу захочется двеНаверное локи будет переделать будет самой меньшей проблемой, особенно если они вынесены в отдельный "модуль".
вот и появилась еще одна зависимость. хуже всего неявная, т.е. едва ли через год кто-нибудь вспомнит, что тормоза идут из-за того, что при развертывании забыли папку перенести на ram-drive
> Наверное локи будет переделать будет самой меньшей проблемой, особенно если они вынесены в отдельный "модуль".
зачем делать так, чтобы потом переделывать, если сразу можно сделать так, чтобы потом не переделывать?
лок мемкэша, по идее, должен быть быстрее, чем файловый локПри всем уважении, мемкешд на соседнем сервере. Но даже если на локальном. Откуда дровишки? Записать в юникс сокет, дождаться ответа от мемкеша быстрее создания пустого файла на современных фс (я не очень уверен, что до диска дело дойдет именно в момент системного вызова)? Насколько?
и с правами еще может быть попроще, файловые локи требуют, чтобы у приложения были права на запись
С правами тож не осознал. Один юзер, одно /tmp.
>как только одной машины перестанет хватать, сразу захочется две
Это уже несмешно. Есть задача, есть прогнозирование нагрузки. Вот что это за преоптимизация пошла? Ну давайте, например, для любого задрипанного сайта-визитки на 10 уникалов в день строить хай-скейл архитектуру. Ну а вдруг!
задрипанного сайта-визитки на 10 уникалов в день строить хай-скейл архитектуру.поднять на аппенжин за 10 минут! Вот те хайскейл архитектура.
Но лучше сайт-визитку написать на яве с использованием энтерпрайз библиотек и оракла
поднять на аппенжин за 10 минут! Вот те хайскейл архитектура.Нет, не подойдет! А вдруг у нас будет такая структура нагрузки и траффика, что дешевле будет написать все с нуля на сях на своей супер специализированной машине, чем платить гуглу за питон-хостинг! Не, ну а вдруг!
запись на винт редко кэшируют
обращение к винту - это 1-10мс
socket память-память может отрабатывать за меньше 1мкс
> С правами тож не осознал. Один юзер, одно /tmp.
это пока у тебя одна машина <-> одна задача всё хорошо.
а если на машине десяток задач крутится, то уже надо аккуратно права раздавать, чтобы дыра в одной задаче не приводила к получению доступа ко всем задачам.
> Есть задача, есть прогнозирование нагрузки. Вот что это за преоптимизация пошла? Ну давайте, например, для любого задрипанного сайта-визитки на 10 уникалов
раз используется мемкэш, то это уже не сайт-визитка.
и раз используется мемкэш, значит бд и соответственно винт уже не справляются с нагрузкой
ты чего оптимизировать собрался? взятие лока для скрипта, который не чаще, чем раз в минуту запускается?
взятие лока для скрипта, который не чаще, чем раз в минуту запускается?откуда появилась инфа про раз в минуту?
раз используется мемкэш, то это уже не сайт-визитка.Мне нравятся категоричные рассуждения на неполной информации. Сервис как бы состоит из многих частей. Мемкешд используется только для одной. Более того, часть, где используется лок, первый кандидат на выброс на другую лоханку. Но не из-за производительности, а ради безопасности.
и раз используется мемкэш, значит бд и соответственно винт уже не справляются с нагрузкой
разрешение крона?
Мемкешд используется только для одной.вот это уже довод, что мемкэш в задаче не используется, и делание локов через него тянет доп. зависимость, которой до этого не было.
здесь уже надо смотреть на "стандарты" всей системы: какое окружение для каждой задачи считается доступным по умолчанию.
зы
лок, кстати, по смыслу накладывать необходимо на всю систему, или на одну машину?
ты чего оптимизировать собрался?это и есть определение говнокода, что сделать можно было за одинаковые ресурсы и лучше, и хуже, а сделали хуже
лок, кстати, по смыслу накладывать необходимо на всю систему, или на одну машину?Лок накладывается на 1 скрипт. Скрипт выполняется с правами владельца файла. Скрипт может запустить крон или ручная операция.
Лок накладывается на 1 скрипт.мы имеем право запустить второй такой же скрипт на другой машине одновременно с первым, или так не стоит?
модератор, а посты не читаешь
модератор, а посты не читаешьответа на этот вопрос не было.
зы
если не понятно почему не было, то советую заботать разницу между терминами может, должен, не должен, не должен одновременно и т.д.
лок мемкэша, по идее, должен быть быстрее, чем файловый локчем? с каких это пор один сискол который меняет структуры в памяти медленнее запроса к другой машине по сети к юзерспейсному демону?
файл на котором делается flock удалять и пересоздавать не обязательно
вот и появилась еще одна зависимость. хуже всего неявная, т.е. едва ли через год кто-нибудь вспомнит, что тормоза идут из-за того, что при развертывании забыли папку перенести на ram-driveКакая ещё зависимость? Мемкеш — вот это зависимость. А папки для локов на некоторых системах уже по умолчанию в tmpfs монируют. Ну про tmpfs я написал если совсем заморочиться надо, а так скорее всего тоже никаких проблем не будет со скоростью. Тем более она навряд ли будет решающей здесь. Т.к. она будет наверняка составлять очень малые доли от времени работы самого скрипта.
зачем делать так, чтобы потом переделывать, если сразу можно сделать так, чтобы потом не переделывать?Я не говорю делать так, чтобы потом обязательно переделывать. А так, чтобы можно было переделать без проблем если понадобится. Это не намного сложнее.
Простой бенчмарк показывает 340ns на пару лок/анлок. Ext4, в один поток.
А вдруг у нас будет такая структура нагрузки и траффика, что дешевле будет написать все с нуля на сях на своей супер специализированной машине, чем платить гуглу за питон-хостинг! Не, ну а вдруг!Влвсе нет ничего удивительного. Аппенжин медленный шописец.
Оставить комментарий
tipnote
Что-то у меня уже крыша едет. Один предлагал через локи мемкеша, другой через локи мускула. Я один такой старпер остался, который думает, что оптимальнее делать через файловые локи типа mkdir, а не через внешние сетевые вызовы к серверам?