Pull to refresh
105
0.2
Евгений Артюхов @jsirex

User

Send message
Да, из-за скачивания холодный старт может быть на 1-2 секунды дольше. Например, вместо 12 секунд будет 14.

У самого есть такая проблема: оптимизировать по каплям, где всё просто и понятно, когда что-то и так работает нормально. Не смотреть в сторону того, что создаёт 90% проблем потому, что там сложнее и чуть менее понятнее.
Level 1.
Официальный openjdk приносит с собой 600 МБ (jre — 450 МБ).
* Если на базе дебиана сделать — то итог 737 мб.
* Если на базе алпайна — то 639 мб.
Сильно выйграть не получиться. А это мы ещё апп внутрь не заливали.

Сделать контейнер меньше всегда хочется и приветствуется. Но никогда не понимал попытку сэкономить на спичках.
Как не читаешь на эту тему что-нибудь: так все работают в гуглах, фейсбуках, нетфликсах и у всех 10к+ машин и 100к+ контейнеров. Как дело доходит до практики — 3 сервера и 5 контейнеров :).
Для стандартных действий — да, кнопку нажать быстрее. Для более менее нестандартных ситуаций — нет. И тут начинается: из gui это сделать вообще можно? Есть там такая фишка? А где? Сколько минут будете лазить пока найдёте?
Use case:
1. Вы что-то там себе в ветке fix-foo делали
2. Потом переключились на dev и продолжили работу.
3. А теперь вас попросили пушнуть ветку fix-foo только под нормальным именем, типа bug/proj-1567-fix-foo

Из консоли это можно сделать одной командой и не будет путаницы в «понимании поведения интерфейса».
В итоге бывает проще выучить 1 инструмент (git cli), чем несколько. Конечно, это не отменяет того, что GUI — удобная штука.

Кстати, пункт 4: пушнуть ветку fix-foo без последнего коммита (потому, что там ерунда) — это всё ещё одна команда.

Но мы должны изначально задать Primary


Может, мы одно и тоже по-разному понимаем, но:
1. Ничего вы не должны.
2. Берём три сервера (будущая реплика). На любом делаем инициализацию.
3. И можно сразу скормить весь конфиг, не делая rs.addWhatEver().
4. Готово.
Возможно, не стоит делать инициализацию на будущем арбитре. Я, чтобы наверняка работало, подключался только к тем серверам, которые могут стать мастером в будущем. Этого достаточно.
У меня было так N серверов для master/slave + 1 сервер арбитер. Я подключался к первому попавшемуся из N и делал rs.conf, скармливая весь список. Реплика инициализируется и работает.
Это для шардированного кластера.
Сервера собираются в репликасет. Репликасеты собираются в общий кластер. Роутер — точка входа, балансер, прокся, вроде бы умел функции агрегации и возможно что-то от map reduce. Но тут боюсь соврать. Лучше почитать доки. Они реально неплохие. Можно потратить 6-8 часов и полностью разобраться что там у монги есть.
Если у вас только репликасет. можете — заставит просто лить в мастер, а слэйвы скопируют всё.
Можно указать replicaset connection string в виде: rsName://host1:port1,host2:port2… — тогда драйвер сам разберётся. Но мне так делать не приходилось. Я восстановление обычно в роутер произвожу. Опять же с шардированным кластером не всегда так можно.
В монге мастера назначать не надо. После выхода из строя мастера происходит голосование и выбор нового мастера автоматически.

multicast удобная штука, но не всегда доступен.
unicast — заставит вас всё равно мейнтейнить список. в принципе для своего кластера сгенерил json, в котором описана топология.
+ есть ещё набор инструментов для развёртывания разных кластеров буквально кнопками, но он платный на сколько мне известно.

Я бы сказал, что у монги с этим всё не так уж и плохо.
Как выяснилось, у того же постгреса всё намного печальнее. Но там и типа базы другой, можно понять.
hello-world:
git remote add prod ansible@2.2.2.2:/path/to/bare/repo
git push prod master

# ..  ну и post-receive hook который сделает checkout
Вот тогда-то и не нужно брать Chef.
А то получается, что делаем «hello world», берём для этого инструмент энтерпрайз уровня и потом волосы <вставить_что_они_делают_при_упоминании_шефа>

Но ближе к существу, мне действительно интересно, что не так с шефом, когда с ним начинаешь знакомиться. Что лично вам не понравилось?
Если в кратце, то никак :)

В ритм играх (допускаю, что конкретно в Guitar Hero это может быть не точно так, как написал), как правило, есть аудиотрек и так называемый simfile — мета-файл в котором и описаны:
  • GAP (OFFSET) — задержка от начала аудиофайла до первой ноты. Авторы часто подгоняют до первой ноты после вступления
  • BPM — темп. Что очень важно, его надо считать очень точно, желательно 5-7 цифр после запятой
  • BPM Changes — обычно время=новый_темп, время=новый_темп и т.д.
  • Delay/Pause — остановки в треке. С нимим есть проблемы точности: паузы вычисляются со своей точностью, которая не совпадает с делением на доли ритма в треке. Их как правило стараются заменить на кратную смену темпа на что-то < 5 и обратно компенсируют. Для таких дел даже скрипт написан
  • Массив данных — собственно, в каждый шаг трека какая нота должна быть сыграна


Вот пример для кнопочной ритм-игры: DDR (ITG).
Там 4 кнопки — поэтому 4 символа в слове для состояния. Разумеется есть редактор, вручную набирать не приходиться:
Cookie Thumper.sm
#TITLE:Cookie Thumper;
#SUBTITLE:;
#ARTIST:Die Antwoord;
#TITLETRANSLIT:;
#SUBTITLETRANSLIT:;
#ARTISTTRANSLIT:;
#GENRE:;
#CREDIT:;
#BANNER:../banner.png;
#BACKGROUND:../bg.png;
#LYRICSPATH:;
#CDTITLE:;
#MUSIC:Cookie Thumper.ogg;
#OFFSET:0.003;
#SAMPLESTART:48.350;
#SAMPLELENGTH:12.000;
#SELECTABLE:YES;
#BPMS:0.000=134.000,107.000=67.000,143.000=134.000;
#STOPS:92.000=0.448
;
#BGCHANGES:;
#KEYSOUNDS:;

//---------------dance-single — Nix----------------
#NOTES:
dance-single:
Nix:
Challenge:
10:
0.631,0.711,0.437,0.164,0.665:
0000
0000
0000
0000
,
0000
0000
0000
0000
,
0000
0000
0000
0000
,
0000
0000
0000
0000
,
0000
0000
0000
0000
,
0000
0000
0000
0000
,
2001
0000
3100
1000
0010
0100
0000
0110
,
0000
0100
0001
0010
1000
0000
0010
0000
,
0011
0000
0001
0100
1000
0100
0000
0110
,
0000
0010
1000
0100
0010
0000
0001
0000
,
1000
0000
1000
0100
0000
0100
0010
0000
0001
0000
0100
0010
1000
0000
0100
0000
,
0010
0001
0010
0100
0000
0100
1000
0010
0100
0000
0001
0000
1001
0000
0000
0001
,
0100
0010
1000
0010
0000
0010
0100
0001
0010
0000
0100
0000
1100
0000
0000
1000
,
0020
0000
0230
0000
0301
0100
0001
0000
0101
0000
1001
0000
2020
0000
3030
0000
,
0120
0000
0130
0001
0100
0010
1000
0000
1100
0000
0110
0000
0011
0000
0000
0000
,
0001
0000
0100
0010
1000
0100
0010
0001
1000
0000
0010
0000
0100
0000
0001
0000
,
0010
0100
1000
0001
0000
0001
1000
0010
0100
0000
0001
0000
0020
0000
0000
0000
,
0030
0000
0000
0000
0100
1000
0100
0010
0001
0000
0100
0000
0110
0000
0000
0000
,
1000
0010
0100
0001
1000
0100
1000
0001
0010
0000
0100
0000
0020
0000
0031
0000
,
0100
0010
0000
1000
0000
0010
0000
0010
0100
0000
0001
0000
1000
0000
0100
0010
,
0001
0010
0100
1000
0000
1000
0001
0100
0010
1000
0010
0000
0100
0000
0000
0000
,
0001
0010
0000
1000
0000
0010
0000
0100
1000
0010
0100
0000
0001
0000
0000
0000
,
1000
0100
0010
0100
0001
0100
0010
0000
0022
0000
0000
0000
0033
0000
1000
0000
,
1010
0000
0010
0100
0001
0000
1000
0000
1100
0000
0000
0000
0100
0000
0100
0010
,
0001
0010
0100
1000
0001
0000
0100
0000
0020
0000
0000
0000
0030
0000
0100
0000
,
0001
0000
0000
0000
1000
0000
1000
0010
0100
0001
0100
0000
0220
0000
0330
0000
,
2002
0000
0000
0000
0000
0000
3003
0000
0001
0000
1000
0001
1000
0000
0000
1000
,
0001
0100
0000
0110
0000
0010
1000
0100
0001
0000
0100
0000
1100
0000
0000
1000
,
0010
0100
0000
0110
0000
0100
0001
0010
1000
0000
0010
0000
0110
0000
0100
1000
,
0010
0100
0000
0101
0000
0001
0010
1000
0001
0000
0100
0000
1100
0000
0100
0010
,
0001
0000
0100
0000
0000
0000
0101
0000
0000
0000
0001
0000
1000
0010
1000
0010
1000
0000
0001
0100
0001
0000
0001
0000
0101
0000
0000
0000
0000
0000
0100
0000
,
0010
1000
0000
1100
0000
0100
0001
1000
0010
0000
0100
0000
1100
0000
1000
0010
,
0100
0001
0000
0011
0000
0010
1000
0010
0001
0000
0100
0000
0110
0000
0010
0001
,
0010
1000
0000
1010
0000
0010
0001
1000
0100
0000
0001
0000
1001
0000
1000
0100
,
0001
0000
0100
0000
0000
0000
1100
0000
0000
0000
1000
0000
0001
0010
0001
0010
0001
0000
1000
0100
1000
0000
1000
0000
0200
0000
0000
0000
0000
0000
M0MM
0000
,
0000
0000
0000
0000
0000
0000
M0MM
0000
0000
0000
0000
0000
0000
0000
M0MM
0000
0000
0000
0000
0000
0300
1000
0001
0000
0101
0000
0000
0000
0000
0000
0000
0000
,
0000
0000
0101
1001
1010
1000
0100
0010
,
0001
0000
0100
0001
1000
0000
0010
0000
0110
0000
0000
0000
0100
0001
1000
0000
,
0100
0000
0000
0010
0000
0000
0001
0000
0000
0010
0000
0000
0100
0000
0000
0000
0000
0000
1000
0000
0000
0000
0000
0000
0010
0000
0000
0000
1000
0000
0100
0000
0000
0000
0000
0000
1100
0000
0000
0000
0000
0000
0000
0000
0000
0110
0000
0000
,
0000
0000
0011
0000
0000
1000
0001
0000
1011
0000
0000
1000
0100
0000
0200
0000
,
0310
0000
0001
0000
0100
0000
1000
0000
0100
0000
0000
0000
0001
0010
0000
1000
,
0000
0001
0000
0100
0010
0000
0001
0000
0100
0000
0000
0000
0010
1000
0000
0001
,
0000
0100
0010
1000
0100
0000
0010
0000
0001
0000
0000
0000
1000
0100
0000
0001
,
0000
0100
1000
0010
1000
0000
0100
0000
0010
0000
0000
0010
0001
0000
0100
0000
,
0010
0000
1000
0010
1000
0000
0100
0000
0010
0000
0000
0000
0010
0000
0100
1000
,
0001
0100
0010
1000
0100
0000
0010
0000
0001
0000
0000
1000
0100
1000
0010
0000
,
0100
0001
1000
0000
0100
0000
0010
0000
0001
0000
0000
0000
0101
0000
0110
0000
,
0010
0000
1000
0010
1000
0010
0100
0000
0001
0000
0010
0000
1000
0000
0010
0000
,
0100
0000
1000
0000
0010
0100
0010
0000
1000
0000
0000
0000
0101
0000
0001
0000
,
0010
0000
0100
1000
0001
1000
0010
0000
0100
0000
0110
0000
1010
0000
0001
0010
,
0100
1000
0100
0010
0001
0000
1000
0000
0010
0000
0100
0000
0001
0010
0001
0000
,
0010
0100
1000
0010
0200
0000
0000
0000
,
0300
0000
0000
0000
;
UPD: УПС: опередили выше про avy
В emacs есть https://github.com/abo-abo/avy
Очень удобно. Работает, даже если открыто несколько виртуальных окон
Я только с третьей попытки залез на emacs. Ни о чём не жалею, да и мне он подходит как нельзя лучше: редактировать разное, скрипты, руби, файлы спец. назначения.
Хорошо организованные настройки творят чудеса. Это как и в обычном программе: всё на своих местах, классы разложены по модулям, ресурсы по папочкам, тесты в своём месте и т.д. и т.п.

Конфиги — это тоже код. Правильно организуй и будет тебе счастье (и много разных подходов на любой вкус).

Мне очень сильно помогло вот это: github.com/purcell/emacs.d
Я форкнул и добавил паручку вещей под себя. Вдруг кому пригодится.
Легко на словах. А на деле не так просто понять.
Вот я залочил базу (слэйв).
Я сделал mongodump. Результат — ок. Ошибок не было. Команда успешно завершена.
Как мне определить, что mongodump отработал не верно?
Делаю restore — ошибка. Плохие данные? Ошибка в restore?
А размер 45 GB дампа.

ПС. И это хорошо, что мы пока коллекции не шардируем. С таким ненадёжным бэкапом если оно упадёт, а все коллекции размазаны по всем базам, до кучи баги роутеров с кэшем, восстановить это будет нереально.

Монгу используем 2.6.6
Восстанавливаю всегда в пустую базу.
noIndexRestore + потом руками — в чём смысл? А если я не знаю какие индексы надо создавать. Ковыряться в дампе и искать их?
А что насчёт автоматизации? Мне надо автоматически раскидывать дампы на разные окружения. И я не могу сделать нормальный restore.

А как же 3 вида админов: кто не делает бэкапы, кто делает и тот кто проверяет :)
Вставлю свои 5 копеек. Может кто-то сталкивался и подскажет как решать вопрос.
Дано: mongodb cluster: 3 config server, 4 shard, каждый shard это реплика из 3х серверов + арбитр.
Шардирования на уровне коллекций нет. У нас много мелких баз и они равномерно размазаны по шардам.
Кластер приложения. Рядом с каждой нодой стоит router.

Баг 1.
Как воспроизвести точно не знаю. Но сценарий такой:
1. Создаём базу main (допустим она попала на sh 001)
2. Пишем туда что-нибудь
3. Удаляем базу (да. нам иногда надо снести базу полностью чтоб просто её пересоздать)
4. Создаём её опять (для примера, она попадает на sh 002)
И вот теперь проблема: роутер через который это делали, знает что база на sh 002. а остальные роутеры видимо хранят кэш и думают что база на sh 001. Последствия катастрофические: пишем документ — ок. тут же читаем — даже базы нету. Или два процесса пишут свои данные в разные базы main.

Баг 2.
Я считаю его практически блокером: отсутствие нормального бэкапа. Да, я читал все мануалы, да, я знаю про mms. Сделать консистентный бэкап — та ещё задача. Но я не придираюсь. Я готов и на «хоть какой-нибудь бэкап кое-как».
Сценарий:
1. Для бэкапа максимально одновременно я блокирую по одному слэйву из каждого шарда на запись.
2. Делаю mongodump (отрабатывает успешно) со всех шардов.
Восстановление: делаю mongorestore — в 70% я получаю duplicate error при попытке построить индекс в конце восстановления. Пробовал и с oplog, и без. Кстати, индекс применяется ДО того как oplog накатывается. Возможно, этот oplog и исправил бы проблему.
Вывод: бэкап вы сделаете. А вот восстановить — как повезёт.
Тут есть ещё разные варианты: я тестировал бэкап через LVM + тянуть прямо с файлов, а не из процесса. Работает стабильнее. Вероятно придётся перейти на этот способ.

Баг 3.
Мутный баг. Иногда просто нельзя удалить коллекцию или базу. Помогает рестарт роутеров.

И это я только с позиции админа. С позицию девелопера я лучше промолчу.

Что конкретно у вас с версиями в Chef не получается?
Если у вас 100+ серверов и chef-client установлен в режиме демона (крутится как клиент, на машине), осторожнее с:

remote_file 'prog' do
  path "#{Chef::Config[:file_cache_path]}/#{package_name}"
  source "http://domain.lan/packages/#{package_name}"
  mode 0644
end

У вас там наверное трафик с этого сервера большой идёт. Каждый запуск chef-client перекачивает этот файл.
Я думал, Facebook сидит на Chef. А есть где почитать как и когда они перешли на cfengine.

И мне не совсем понятен вопрос производительности? Какая разница 100, 1000, 10000? Точнее, она там есть, но тогда причём тут руби?
Всю жизнь пользуюсь aptitude.
Нигде ничего не сломалось. ЧЯДНТ?
В отличии от Супермена, Бэтмэну нужно потратить время на то, чтобы этот криптонит взять и ещё умудриться напасть на Супермена с ним.
Супермен же, в свою очередь, может держаться на расстоянии 100 км и при первом же намёке, что Бэт задумал что-то неладное, скинуть на него целую гору. В данном случае, Супермен — это НЕ сбалансированный персонаж. Имба. И всё тут.

Information

Rating
2,159-th
Location
Польша
Date of birth
Registered
Activity