Pull to refresh
65
0
Андрей Черных @akhkharu

User

Send message
При всей моей нелюбви к Microsoft, нужно отдать должное Биллу Гейтсу. Побольше бы таких благотворителей, как он. Очень печально, что самый популярный ответ в опросе — до 10 миллиардов :(
Там всё-таки миллионов, а не миллиардов, поэтому далеко не самая большая сумма.
После этого сбоя успешно потеряли RDS-инстанс. Пришлось восстанавливаться из Point-in-Time бэкапа.
Очень удобно пользоваться monit-ом. После настройки в рецепт можно просто добавить следующее:

run "monit restart delayed_job.0 delayed_job.1 delayed_job.2 delayed_job.3"
Большое спасибо за информацию, не знал, что ActiveRecord сериализуется достаточно эффективно.

Забыл отметить, что обычно background-задачи мы запускаем на отдельных машинах, поэтому иногда позволяем себе запускать количество воркеров большее, чем количество потоков. Используем удалённое соединение к MySQL так как работа с файлами не ведётся.

Дедлоки в MySQL вещь достаточно обычная для Rails-прилоежений и они случаются не только в случае нескольких воркеров, но и просто на высоконагруженных серверах. Решается это обычно вынесением модельной логики из after_save/after_create в after_commit чтобы сделать транзакции как можно быстрее. MySQL, кстати, такие транзакции находит и убивает по истечении заданного времени, так что ничего критичного кроме временной блокировки процессов в этом нет.
Это понятно, что для всего есть своя консольная утилита. Разница в том, что в вашем скрипте эту консольную утилиту нужно правильно использовать, да ещё и тщательно это простестировать. А если в один прекрасный день сторонний сервис, на который заливаются ваши бэкапы откажет / истечёт срок действия сертификата / закончатся деньги в аккаунте? Гем backup умеет отправлять письма на почту со статусом последнего бэкапа.

Кроме того, в вашем скрипте нет обработки кодов возврата. А ведь каждая команда в цепочке может выполнится неуспешно (ошибка доступа, закончилось место на диске, MySQL timeout).

Я не совсем правильно выразился по поводу возможных предметов бэкапа. Бэкапятся, в любом случае, только файлы. Более или менее нагруженный проект это не только LAMP. У нас в проекте, например, есть Redis. Он периодически сохраняет свою базу в файл. Перед тем как копировать эту базу для бэкапа, нужно отправить специальную команду для того, чтобы Redis записал информацию на диск. Понятно, что это тоже можно реализовать с помощью bash-скрипта, но зачем изрбретать велосипед, если это уже сделали правильно за тебя и нужно лишь указать путь к папке Redis в конфиге? Чем сложнее проект, тем больше велосипедов придётся изобретать.
41 открытый вопрос — это лишь показатель популярности проекта. Software fails.

Недостаток простых скриптов в том, что рано или поздно их приходится дописывать / делать костыли. К примеру, если захотите бэкапится на S3 вместо диска, либо захотите делать бэкапы инкрементально. Я раньше тоже пользовался самописным скриптиком вроде вашего, но понял, что использовать его для сложных проектов стало неудобно из-за того, что в некоторых местах бэкапить нужно не только файлы/БД.
Для бэкапов рекомендую вот эту штуку:

github.com/meskyanichi/backup
Если нужен именно глобальный фид, то я бы предложил использовать отдельный Sorted Set, в который автоматически будут добавляться активити всех юзеров при создании. Дело в том, что значениями в Sorted Set выступают названия Set-ов, которые уникальны для каждой активити и не дублируются. То есть, если один юзер создаёт активити, то в фиды всех подписчиков добавляется ссылка на один и тот же Set.
Фиды у нас хранятся в виде Sorted Sets для каждого пользователя, в которых зачениями выступают названия других ключей, которые являются Set. Это делается для группировки однотипных событий. Необходимости показывать объединённые фиды пока не возникало, но я думаю, что можно попробовать использовать ZUNIONSTORE.
Таких недостатков для себя не нашёл, просто нет в этом необходимости, достаточно RDB.
Спасибо за информацию, я добавил в пост ссылку на FAQ.

Даже если папа очень интенсивно пишет, то всё упирается в скорость записи данных на диск. Теория такова, что пока детка пишет на диск, папа может изменить все ключи, но на практике детка всё-таки успевает всё быстренько записать и рост используемой памяти за это время минимальный. Зависит от объёмов данных и количества частоизменяемых ключей, конечно. У нас в настоящий момент Redis использует 3Gb и пишет это всё на диск (попутно сжимая) секунд за 30 (EC2 moderate IO performance).
Хинт: публичный ключ быстро копируется на другой сервер при помощи ssh-copy-id либо github.com/mattwynne/ssh-forever.
Затрудняюсь с ответом. Вероятно, Вам действительно поможет JS API плееров. Так же, посмотрите в сторону RTMP (http://flowplayer.org/plugins/streaming/rtmp.html).
Оставляем оригинальные, но, действительно, нужно менять на синтетические. Спасибо за подсказку.
Насколько я знаю, mplayer в любом случае выдаёт скриншоты именно по ближайшим кейфреймам.
На Mac OS X такой проблемы нет. Есть проблема в iOS, там флэшовые ролики открываются только при помощи специализированного ПО вроде skyfire (http://skyfire.com). В Safari Flash-видео не работает.
Очень интересный опыт и оригинальная реализация очереди. Спасибо.
У вас не возникло проблем с загрузкой больших файлов при помощи SWF Uploader? У меня и моего коллеги стабильно наблюдались подвисания браузеров для файлов > 200-300Mb. Поэтому решили использовать обычную загрузку через HTTP.
Основной сервер — steadfast.net/services/dedicated.basic.php (Twelve Cores (Westmere))
Файловые сервера — Xeon X3430 2.4Ghz, 4Gb RAM, 2x1Tb HDD

Information

Rating
Does not participate
Location
Казань, Татарстан, Россия
Date of birth
Registered
Activity