Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 96
От себя сразу могу сказать, что конечно-же идея хорошая (и правильная), но код немножко сыроват.
Надёжность FS выже надёжности MySQL просто потому что MySQL на FS опирается в работе.
Надёжность FS выже надёжности MySQL просто потому что MySQL на FS опирается в работе.
> Надёжность FS выже надёжности MySQL просто потому что MySQL на FS опирается в работе.
«надёжность IEEE 802.11b выше надёжности TCP/IP просто потому что TCP/IP опирается в работе на IEEE 802.11b»
«надёжность IEEE 802.11b выше надёжности TCP/IP просто потому что TCP/IP опирается в работе на IEEE 802.11b»
надёжность одного отдельного винчестера выше надёжности RAID-1 просто потому что RAID-1 опирается в работе на отдельные винчестеры
Прикольно передёргиваете. Сразу видно профессионала.
во-первых, у вас ошибка в словах «MySQL на FS опирается в работе», потому что, в частности, InnoDB может работать без файловой системы, напрямую с RAW-партишном.
во-вторых (и самое важное), у вас ошибка в «потому что», потому что высказывание «Надёжность FS выже надёжности MySQL» не находится в причинно-следственной связи с высказыванием «MySQL на FS опирается в работе».
при этом своими комментариями я (внимание) не оспариваю и не подтверждаю, что «Надёжность FS выже надёжности MySQL» — я не знаю, так это или не так. я оспариваю, что, даже если надёжность FS выше надёжности MySQL, то это вовсе не потому, что «MySQL на FS опирается в работе»
во-вторых (и самое важное), у вас ошибка в «потому что», потому что высказывание «Надёжность FS выже надёжности MySQL» не находится в причинно-следственной связи с высказыванием «MySQL на FS опирается в работе».
при этом своими комментариями я (внимание) не оспариваю и не подтверждаю, что «Надёжность FS выже надёжности MySQL» — я не знаю, так это или не так. я оспариваю, что, даже если надёжность FS выше надёжности MySQL, то это вовсе не потому, что «MySQL на FS опирается в работе»
InnoDB может работать без файловой системы
Everything is file. Нельзя работать с устройством без файловой системы: VFS и сотоварищи незримо присутствуют.
Сделайте перед запуском rm -f /dev/* и посмотрите, что получится у mysqld и InnoDB.
я оспариваю
Надёжность A не может быть выше надёжности B, если A в своей работе использует только один экземпляр B. А код FS у MySQL ровно один — одно ядро используется (mysql-cluster и подобные это другая история, они используют не один экземпляр FS).
Everything is file. Нельзя работать с устройством без файловой системы: VFS и сотоварищи незримо присутствуют.
Сделайте перед запуском rm -f /dev/* и посмотрите, что получится у mysqld и InnoDB.
я оспариваю
Надёжность A не может быть выше надёжности B, если A в своей работе использует только один экземпляр B. А код FS у MySQL ровно один — одно ядро используется (mysql-cluster и подобные это другая история, они используют не один экземпляр FS).
замечательно.
надёжность FS выже надёжности MySQL просто потому что можно удалить /dev/* или /etc/mysql/* НУ И ГДЕ ВАША MYSQL ТЕПЕРЬ?!?
обычно, когда говорят о «надёжности FS», то подразумевают такие штуки, как журналирование, алгоритм выделение блоков, записывается ли при перезаписи файл на старое место или на новое, всякие такие вещи. а вы, оказывается, говорили о том, что нужно отнять у mysql доступ к /dev/
super!
super!
Да-да. Передёргивайте дальше :-)
У слова «Надёжность на некотором отрезке времени» есть ровно одно значение: $1 — вероятность отказа за этот отрезок времени$.
Я лишь показал, что MySQL зависит от FS на настолько простом уровне, что даже InnoDB не сможет стартовать если /dev созданы неправильно. Не говоря уже о записи в файлы.
У слова «Надёжность на некотором отрезке времени» есть ровно одно значение: $1 — вероятность отказа за этот отрезок времени$.
Я лишь показал, что MySQL зависит от FS на настолько простом уровне, что даже InnoDB не сможет стартовать если /dev созданы неправильно. Не говоря уже о записи в файлы.
мы говорим о сферических mysql в вакуумах?
ну, по-моему, довольно очевидно, что когда мы говорим о MYSQL, то мы подразумеваем, что MySQL установлена, все зависимые библиотеки тоже установлены, они лежат по тем путям, по которым их будет искать mysql, всё это работает, у mysql есть конфиг, mysql правильно сконфигурирована, мы знаем пароль, мы можем подключиться к ней, у нас есть права на доступ к конкретной БД, мы можем сделать запрос
ну, по-моему, довольно очевидно, что когда мы говорим о MYSQL, то мы подразумеваем, что MySQL установлена, все зависимые библиотеки тоже установлены, они лежат по тем путям, по которым их будет искать mysql, всё это работает, у mysql есть конфиг, mysql правильно сконфигурирована, мы знаем пароль, мы можем подключиться к ней, у нас есть права на доступ к конкретной БД, мы можем сделать запрос
Надёжность (англ. reliability) — свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования (ГОСТ 27.002—89).
то есть да, вероятность, но при определённых условиях.
в частности, обеспечив существование /dev/… и /etc/mysql/my.cnf (что просто: достаточно сетевой загрузки и NFS'а), и сравнивая надежность mysql на отдельном диске против надежности ФС на том же диске, мы получим, что mysql надёжней.
то есть да, вероятность, но при определённых условиях.
в частности, обеспечив существование /dev/… и /etc/mysql/my.cnf (что просто: достаточно сетевой загрузки и NFS'а), и сравнивая надежность mysql на отдельном диске против надежности ФС на том же диске, мы получим, что mysql надёжней.
>и сравнивая надежность mysql на отдельном диске против надежности ФС на том же диске, мы получим, что mysql надёжней.
Слова, конечно, не интересны. Покажите, почему mysql надёжнее. Простая задача: предоставить механизм когда mysql работает после 100 запросов после крушения файловой системы.
Слова, конечно, не интересны. Покажите, почему mysql надёжнее. Простая задача: предоставить механизм когда mysql работает после 100 запросов после крушения файловой системы.
я соглашусь с утверждением, что mysql менее надёжен, чем ядро и devfs, благодаря которым он имеет доступ к raw partition.
devfs-то тут причём? Доступ к raw идёт только через VFS, а файлы устройств может создавать кто угодно.
И-таки приведите пример, когда mysql работает после 100 запросов.
да при чём тут 100 запросов?
mysql. вы делаете insert'ы и update'ы в innodb/mysql в несколько потоков одновременно. и в середине этого процесса вырубаете питание. если клиент был удалённым, то незакоммиченные транзакции закоммитить уже не получается. при включении питания вы убеждаетесь, что те транзакции, которые закоммитились, действительно закоммитились. те транзакции, которые не закоммитились, действительно не закоммитились.
теперь файлы. речь же у нас ФС на накопителе с постоянной памятью, правда? пишем файлы. во много потоков. отключаем питание. включаем питание. какие-то файлы добавились, какие-то — проебались. причём, если мы делали это с удалённого хоста, то какие-то файлы якобы сохранились, но на самом деле нет.
соответственно, функцию «сохранить данные и сообщить об успехе, либо сообщить об ошибке» mysql выполняет надёжнее
mysql. вы делаете insert'ы и update'ы в innodb/mysql в несколько потоков одновременно. и в середине этого процесса вырубаете питание. если клиент был удалённым, то незакоммиченные транзакции закоммитить уже не получается. при включении питания вы убеждаетесь, что те транзакции, которые закоммитились, действительно закоммитились. те транзакции, которые не закоммитились, действительно не закоммитились.
теперь файлы. речь же у нас ФС на накопителе с постоянной памятью, правда? пишем файлы. во много потоков. отключаем питание. включаем питание. какие-то файлы добавились, какие-то — проебались. причём, если мы делали это с удалённого хоста, то какие-то файлы якобы сохранились, но на самом деле нет.
соответственно, функцию «сохранить данные и сообщить об успехе, либо сообщить об ошибке» mysql выполняет надёжнее
Если вы вырубить питание внезапно в середине записи транзакций, то не факт что запись успеет дойти до всех кэшов. Можно и битую таблицу получить, то есть отказ.
Сильно сомневаюсь, что MySQL в при COMMIT'е выполняет fsync().
Мы какие-то разные надёжности рассматриваем. Я — на полный отказ, вы — на частичный.
Сильно сомневаюсь, что MySQL в при COMMIT'е выполняет fsync().
Мы какие-то разные надёжности рассматриваем. Я — на полный отказ, вы — на частичный.
Странно, что MySQL'ю Вы прощаете незакоммиченые транзакци, а FS — не прощаете не до конца записанные файлы. То, что транзакция была отправлена но не была записана — это отказ.
И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
нет, я не прощаю ничего мусклю. просто mysql, если закоммитила транзакцию (и сообщила об успешном результате), то транзакция уже не потеряется, а если FS записала файл (и сообщила об успешном результате), то это ещё ничего не значит.
собственно, поэтому fsck fsck fsck и делается.
> И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
нет, отказ как раз будет разным. и тот и другой сообщат об ошибке, но у FS могут быть файлы, которые вроде как записались, но на самом деле нет.
собственно, поэтому fsck fsck fsck и делается.
> И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
нет, отказ как раз будет разным. и тот и другой сообщат об ошибке, но у FS могут быть файлы, которые вроде как записались, но на самом деле нет.
Да, в этом случае, MySQL «надёжнее» FS на которую она опирается. Однако это не-ГОСТовый смысл.
Вам, видимо, достаточно сообщения об ошибке. Я считаю, что ошибка, даже с сообщением (и тем более без) — это уже отказ. ГОСТ, видимо, про сообщениях об ошибках ничего не знает.
То есть когда девушка разворачивается и уходит или говорит «нет, потому что ...» (EBUSY) — это отказ и так и так. Только в одном случае причина понятна, и с ней можно бороться (найти другой экземпляр девушки), а в другом — нет.
В общем, я согласен, что MySQL иногда говорит об ошибках лучше, чем FS. Однако не считаю, что это делает его надёжнее (однако позволяет сделать более очевидным отказ приложения опирающегося на MySQL, по сравнению с приложением на FS).
Вам, видимо, достаточно сообщения об ошибке. Я считаю, что ошибка, даже с сообщением (и тем более без) — это уже отказ. ГОСТ, видимо, про сообщениях об ошибках ничего не знает.
То есть когда девушка разворачивается и уходит или говорит «нет, потому что ...» (EBUSY) — это отказ и так и так. Только в одном случае причина понятна, и с ней можно бороться (найти другой экземпляр девушки), а в другом — нет.
В общем, я согласен, что MySQL иногда говорит об ошибках лучше, чем FS. Однако не считаю, что это делает его надёжнее (однако позволяет сделать более очевидным отказ приложения опирающегося на MySQL, по сравнению с приложением на FS).
Кстати. А стены надёжнее фундамента?
Потому, что MySQL опирается на FS. Если FS порушится и удалится конфиг-файл MySQL то он и не запустится.
Если FS откажет, то MySQL встанет боком и свистнет раком. Если MySQL откажет, то FS этого и не заметит.
Разве это не очевидный результат из теории вероятности? Более сложный компонент опирается на простой -> вероятность отказа сложного не меньше, чем простого.
Если FS откажет, то MySQL встанет боком и свистнет раком. Если MySQL откажет, то FS этого и не заметит.
Разве это не очевидный результат из теории вероятности? Более сложный компонент опирается на простой -> вероятность отказа сложного не меньше, чем простого.
помимо полных отказов, существуют также риски потери данных.
1. например, вы создаёте и редактируете кучу мелких файлов в несколько потоков одновременно. и в середине этого процесса вырубаете электричество.
2. например, вы делаете insert'ы и update'ы в innodb/mysql в несколько потоков одновременно. и в середине этого процесса вырубаете электричество.
в первом случае у вас пропадёт несколько последних секунд, плюс какие-то файлы получатся битые — часть файла содержат старые данные, часть — новые данные; могут даже повредиться директории.
во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!
обычно под надёжностью понимается именно это. разве не так?
1. например, вы создаёте и редактируете кучу мелких файлов в несколько потоков одновременно. и в середине этого процесса вырубаете электричество.
2. например, вы делаете insert'ы и update'ы в innodb/mysql в несколько потоков одновременно. и в середине этого процесса вырубаете электричество.
в первом случае у вас пропадёт несколько последних секунд, плюс какие-то файлы получатся битые — часть файла содержат старые данные, часть — новые данные; могут даже повредиться директории.
во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!
обычно под надёжностью понимается именно это. разве не так?
> могут даже повредиться директории.
Не читайте советских газет во время обеда. © Профессор Преображенский.
А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS — то ничего не повредится даже в этом случае. Как я уже сказал: A не может быть надёжнее B в случае если B использует один экземпляр A. Это же аксиома надёжности электрических цепей.
> во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!
Здорово! Только данные там будут не все, и это уже отказ (потеря надёжности).
Ещё раз: у нас под надёжностью понимается вероятность неотказа на некотором промежутке времени. Вы используете своё, особое, определение надёжности, определяемое на журналиуремость и выделение блоков.
Не читайте советских газет во время обеда. © Профессор Преображенский.
А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS — то ничего не повредится даже в этом случае. Как я уже сказал: A не может быть надёжнее B в случае если B использует один экземпляр A. Это же аксиома надёжности электрических цепей.
> во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!
Здорово! Только данные там будут не все, и это уже отказ (потеря надёжности).
Ещё раз: у нас под надёжностью понимается вероятность неотказа на некотором промежутке времени. Вы используете своё, особое, определение надёжности, определяемое на журналиуремость и выделение блоков.
> А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS
прекрасно. то есть теперь вы говорите не то, что «FS надёжней MySQL», а то, что «хорошая FS надёжней MySQL». это в каком-то смысле прогресс.
под надёжностью я и все разумные люди всё-таки подразумеваем «свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования (ГОСТ 27.002—89).»
если бы вы читали, что я вам пишу, вы бы смогли его увидеть. уверяю вас, я не использую своего определения. вообще, где вы там определение увидели-то?
прекрасно. то есть теперь вы говорите не то, что «FS надёжней MySQL», а то, что «хорошая FS надёжней MySQL». это в каком-то смысле прогресс.
под надёжностью я и все разумные люди всё-таки подразумеваем «свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования (ГОСТ 27.002—89).»
если бы вы читали, что я вам пишу, вы бы смогли его увидеть. уверяю вас, я не использую своего определения. вообще, где вы там определение увидели-то?
> то есть теперь вы говорите не то
Нет, теперь вы выдернув из контекста мои фразы пытаетесь заставить меня такое сказать.
MySQL опирающаяся на FS не может быть надёжнее последней. В случае отказа FS, которую использует MySQL, MySQL откажет так же.
> под надёжностью я и все разумные люди всё-таки подразумеваем
Это уже ad hominem.
Хорошо. Когда у вас есть фундамент, а потом вы строите над ним дом, то фундамент является отдельным объектом, а дом без фундамента объектом не является (поскольку фундамент в доме неустраним без разрушения дома).
Тогда способность дома выполнять требуемые функции в заданных режимах и условиях применения зависит от способности фундамента, как составной части, делать это. То есть надёжность фундамента входит в надёжность дома (в том числе и при расчёте).
Нет, теперь вы выдернув из контекста мои фразы пытаетесь заставить меня такое сказать.
MySQL опирающаяся на FS не может быть надёжнее последней. В случае отказа FS, которую использует MySQL, MySQL откажет так же.
> под надёжностью я и все разумные люди всё-таки подразумеваем
Это уже ad hominem.
Хорошо. Когда у вас есть фундамент, а потом вы строите над ним дом, то фундамент является отдельным объектом, а дом без фундамента объектом не является (поскольку фундамент в доме неустраним без разрушения дома).
Тогда способность дома выполнять требуемые функции в заданных режимах и условиях применения зависит от способности фундамента, как составной части, делать это. То есть надёжность фундамента входит в надёжность дома (в том числе и при расчёте).
я с вами согласен, но нужно определиться, что мы меряем.
потому что я считаю, что нужно сравнивать надёжность дома vs надёжность фундамента соседского сарая. а вы хотите сравнить надёжность дома vs надёжность фундамента того же дома. естественно, что фундамент надёжнее, но достаточно установить ECC-фундамент, и его надёжность будет пренебрежимо мало отличаться от 1.
потому что я считаю, что нужно сравнивать надёжность дома vs надёжность фундамента соседского сарая. а вы хотите сравнить надёжность дома vs надёжность фундамента того же дома. естественно, что фундамент надёжнее, но достаточно установить ECC-фундамент, и его надёжность будет пренебрежимо мало отличаться от 1.
А надёжность современных компьютерных программ пренебрежимо мало отличается от 1. Настолько мало, что меряются уже -log(1-надёжность).
Вы хотите сказать, что надёжность MySQL не зависит от надёжности FS? Да, в специальном случае когда вы пишите в raw-device. Но даже в этом случае какая-то FS может порушить стэк VFS и это приведёт к краху MySQL.
Что бы исправить ошибку связанную с конкретной FS достаточно иногда записать в другое место, но это уже другой экземпляр FS, и вероятности отказа будут считаться иначе.
Вы хотите сказать, что надёжность MySQL не зависит от надёжности FS? Да, в специальном случае когда вы пишите в raw-device. Но даже в этом случае какая-то FS может порушить стэк VFS и это приведёт к краху MySQL.
Что бы исправить ошибку связанную с конкретной FS достаточно иногда записать в другое место, но это уже другой экземпляр FS, и вероятности отказа будут считаться иначе.
$fp = fopen("/корень/var/flock",«w+»);
if (flock($fp, LOCK_EX + LOCK_NB)) {
//код задачи
} else {
echo «Already running»;
exit;
}
Так более надёжнее лок задачи с помощью файла. В вашем случаи если скрипт повиснет, то ждать обработки придется 10800 секунд.
if (flock($fp, LOCK_EX + LOCK_NB)) {
//код задачи
} else {
echo «Already running»;
exit;
}
Так более надёжнее лок задачи с помощью файла. В вашем случаи если скрипт повиснет, то ждать обработки придется 10800 секунд.
Не ново… Не хватает:
1) возможность указания кол-ва одновременных паралелльных процессов(например, ровно 10)
2) возможность хранить в базе с кучей собственных параметров и выполнять по eval'у
3) функционал управления алертами и логгированием о выполненных задачах
4) отслеживание выполнения джобов в базе
1) возможность указания кол-ва одновременных паралелльных процессов(например, ровно 10)
2) возможность хранить в базе с кучей собственных параметров и выполнять по eval'у
3) функционал управления алертами и логгированием о выполненных задачах
4) отслеживание выполнения джобов в базе
Я поясню почему говорю об этом. У нас, например, часто генерируются большие и долгие отчеты, кроме того ежедневно, еженедельно и ежемесячно проводятся кучи всяких работ в том числе и автогенерация отчетов и прочее. Поэтому время запуска отложенные задания настроены как на выполнение в определенное время, так и просто — например, щелкнули — выдать отчет такой-то. Отчет выполняться может до 10 минут. Если ставить все это делать по-одному, то кто-то может вместо 10 минут, ждать полчаса, т.к. вместе с ним еще несколько отделов дали задания сделать свои отчеты.
Лучше лочить тогда каждый файл задачи отдельно. Это уже подробности реализации cron-сервера.
Можете, например, форки из pcntl заюзать, раньше они были нестабильные, поэтому эта часть у нас на перле была всегда.
Вместо очередного велосипеда: gearman.org
А на хостингах как быть?
Если вы будете выполнять «ресурсоёмкие задачи», как написано в заголовке — вас просто выпрут с шареда. А VDS по-моему сейчас не такой уж и дорогой.
Топик назван не корректно, надо переименовать, наверное. Задачи-же могут быть не только ресурсоёмкими но и просто медленными: связь с удалённым хостом, отсылка данных, ручная проверка.
Тут этот класс является достаточно неплохим минимальным решением.
Тут этот класс является достаточно неплохим минимальным решением.
Ну, и, конечно, ресурсоёмкость разная бывает: если задача чуть сложнее добавления task'а в очередь и её возвращаемое значение не интересно прямо сейчас, то можно отложить и на потом. Правда, смысла в таком мало.
Вместо очередного gearman.org велосипеда: Globus Toolkit
А грид-вычисления здесь причём? С таким же успехом можно и mapreduce/hadoop сюда приплести.
Википедия про gearman как про mapreduce и думает: WIKI
А при том, что фактически эту работу может делать и globus toolkit. И создан он раньше. И уровень защищённости у него больше. И используется больше. Ну, то есть, по сравнению с ним — gearman совсем новый велосипед.
Хотя, конечно, задачи совершенно у них разные и в первую очередь разный «вес». Как и у приведённого кода класса и gearman, отношение приблизительно такое.
А при том, что фактически эту работу может делать и globus toolkit. И создан он раньше. И уровень защищённости у него больше. И используется больше. Ну, то есть, по сравнению с ним — gearman совсем новый велосипед.
Хотя, конечно, задачи совершенно у них разные и в первую очередь разный «вес». Как и у приведённого кода класса и gearman, отношение приблизительно такое.
В википедии написано что gearman концептуально похож на mapreduce. Mapreduce можно реализовать на gearman, но это не из этого не следует, что это единственная задача которую gearman может решить. Основное назначение gearman — отложенные вычисления, т.е. именно то, о чём и написано в посте.
Ваше дилетантское сравнение с globus toolkit порадовало. Вы не понимаете чем грид-вычисления отличаются от отложенных вычислений. Да, при желании с помощью gearman можно реализовать и грид-вычисления, но опять-таки это не основное его назначание. Также хотелось бы знать в чём вы меряете «уровень защищенности» и откуда у вас данные о частоте использования globus toolkit в сравнении с gearman (хотя как вообще можно их сравнивать, если они решают разные задачи?).
Ваше дилетантское сравнение с globus toolkit порадовало. Вы не понимаете чем грид-вычисления отличаются от отложенных вычислений. Да, при желании с помощью gearman можно реализовать и грид-вычисления, но опять-таки это не основное его назначание. Также хотелось бы знать в чём вы меряете «уровень защищенности» и откуда у вас данные о частоте использования globus toolkit в сравнении с gearman (хотя как вообще можно их сравнивать, если они решают разные задачи?).
То есть, получается, «приплести mapreduce» тут можно?
Gearman, прежде всего, для передачи вычислений на другую машину создан. Отложить в нём задачу а потом спросить «как она там» в нём не вижу как. Подскажите, если можно.
При помощи globus toolkit можно и отложенные вычисления реализовывать, он для этого сгодится. (Я никогда не говорил, что это одно и то же, только лишь что globus toolkit умеет делать работу gearman давно). Но опять-же, это по воробьям из пушки. И при помощи gearman можно (и довольно хорошо) делать простые grid-системы. Это как слону дробинка.
Но и gearman для отложенных вычислений на хостинге — это слишком тяжеловесное решение.
Про частоту использования: давайте сравнивать количество машинного времени (в flops'ах), которую обработал globus toolkit и gearman. Разницу будет видно, думаю, сразу.
Про защищённость: не смог найти в документации по gearman как на нём авторизовываться и как данные предотвращаются от перехвата (шифрование). Может, документация старая. Сейчас гляну исходники.
Gearman, прежде всего, для передачи вычислений на другую машину создан. Отложить в нём задачу а потом спросить «как она там» в нём не вижу как. Подскажите, если можно.
При помощи globus toolkit можно и отложенные вычисления реализовывать, он для этого сгодится. (Я никогда не говорил, что это одно и то же, только лишь что globus toolkit умеет делать работу gearman давно). Но опять-же, это по воробьям из пушки. И при помощи gearman можно (и довольно хорошо) делать простые grid-системы. Это как слону дробинка.
Но и gearman для отложенных вычислений на хостинге — это слишком тяжеловесное решение.
Про частоту использования: давайте сравнивать количество машинного времени (в flops'ах), которую обработал globus toolkit и gearman. Разницу будет видно, думаю, сразу.
Про защищённость: не смог найти в документации по gearman как на нём авторизовываться и как данные предотвращаются от перехвата (шифрование). Может, документация старая. Сейчас гляну исходники.
Кстати, а detach'иться от помещённых заданий в нём можно? Так, что бы потом можно было проверять статус задачи на лету и получать часть данных которая уже готова? Что-то не могу найти в коде perl-клиента.
А то предстоит мне одну вебморду для научных вычислений делать, как раз такая штука нужна.
А то предстоит мне одну вебморду для научных вычислений делать, как раз такая штука нужна.
gearman.org/index.php?id=protocol
Можно детачиться и получать статус выполнения. Получать данные частями — либо уже можно, либо будет возможно в будущем, точно не помню. У воркера есть сообщение WORK_DATA, наверное это то, что вам нужно.
Eric Day говорил об этом в одном из докладов. Если не лень, можете поискать в его презентациях, их хоть и много, но они не сильно отличаются друг от друга.
Можно детачиться и получать статус выполнения. Получать данные частями — либо уже можно, либо будет возможно в будущем, точно не помню. У воркера есть сообщение WORK_DATA, наверное это то, что вам нужно.
Eric Day говорил об этом в одном из докладов. Если не лень, можете поискать в его презентациях, их хоть и много, но они не сильно отличаются друг от друга.
Нет, вроде это делает GET_STATUS, умеет отдавать процент от выполненного. Нужно, конечно, всегда смотреть код. А то мало-ли.
Думаю, удастся ли убедить админа поставить gearman и имеет ли смысл делать такой патч. Не можете разузнать, хотят ли они реализации отдачи данных кусками? Тогда можно будет написать патч.
Думаю, удастся ли убедить админа поставить gearman и имеет ли смысл делать такой патч. Не можете разузнать, хотят ли они реализации отдачи данных кусками? Тогда можно будет написать патч.
Всмысле, WORK_DATA не умеет этого делать для background задач.
WORK_DATA, WORK_WARNING, WORK_STATUS, WORK_COMPLETE,
WORK_FAIL, WORK_EXCEPTION
For non-background jobs, the server forwards these packets from
the worker to clients. See «Worker Requests» for more information
and arguments.
А вот статус получить можно.
WORK_DATA, WORK_WARNING, WORK_STATUS, WORK_COMPLETE,
WORK_FAIL, WORK_EXCEPTION
For non-background jobs, the server forwards these packets from
the worker to clients. See «Worker Requests» for more information
and arguments.
А вот статус получить можно.
По идее WORK_DATA должен отдавать эти данные серверу на хранение для не-бекграундных воркеров. Как будет на самом деле — не знаю, не смотрел.
Патчу наверное будут рады, но у них были планы переписать gearman на C++, поэтому не исключено, что патч сейчас могут и не принять. В любом случае общаться по этому поводу нужно не со мной, а скорее всего с Эриком.
Патчу наверное будут рады, но у них были планы переписать gearman на C++, поэтому не исключено, что патч сейчас могут и не принять. В любом случае общаться по этому поводу нужно не со мной, а скорее всего с Эриком.
Ответил: отдаёт WORK_DATA, но сервер их игнорирует.
В версии 0.13 смотрите (cd ./libgearman-server):
1) Добавление задачи в server.c, стр 272: server_client = NULL;
2) Обработка WORK_DATA в server.c, 485,
3) Выполнение _server_queue_work_data, добавлине данных в очередь, проходит по списку server_client. См. server.c стр. 959.
В версии 0.13 смотрите (cd ./libgearman-server):
1) Добавление задачи в server.c, стр 272: server_client = NULL;
2) Обработка WORK_DATA в server.c, 485,
3) Выполнение _server_queue_work_data, добавлине данных в очередь, проходит по списку server_client. См. server.c стр. 959.
Вот и получается, что для того что бы сделать это на PHP с этим PHP-классом мне нужно лишь поправить его, а для gearman нужно будет поправить исходник и библиотеку, линковать с PHP и так далее.
Не умеет, я посмотрел код. Если вы запускаете задачу в BG, для неё просто не создаётся структура хранящая обмен между клиентом и сервером, в которую данные WORK_DATA записываются.
Совет на будущее — возьмите на вооружение конвенции ZF/PEAR coding style, который на сегодняшний день практически является стандартом, и приведите к ним ваш код, напишите нормальные phpdoc-комментарии — это повысит его ценность вдесятеро. После этого можно уже можно будет обсуждать достоинства/недостатки реализации.
Чем больше параметр priority, тем дальше отложится задача.Может стоило сделать наоборот? Ведь логичнее выполнять сперва задачи с более высоким приоритетом.
не ново
Не хватает выполнение через определенное количество времени.
Например я добавляю — обновить информацию через определенно количество времени.
Например я добавляю — обновить информацию через определенно количество времени.
А есть чтото подобное на memcached/apc/redis?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Медленные и/или ресурсоёмкие задачи в коде: отложенные задания, очереди, задачи с ручной обработкой