Да, кстати, если уж и сравнивать, то unicorn и rainbows!, то последний основан на первом. Основное отличие — разные задачи использования. Задача unicorn — обслуживание быстрых запросов, в то время как для rainbows! — долго «живучих» запросов. Поэтому первый хорош для простых сайтов с запрос-ответ (тоесть почти для всех веб сайтов), а второй для обслуживание websocket или commet соединений.
Это не поводу убивать процесс — там может выполнятся важная задача (например, идет работа с платежом от клиента). Если все написано без особой магии, то Ruby GC почистить обьекты и память вернется на место.
У puma это есть, но вот стабильностью «phased-restart» похвастаться пока не может. Самый частый случай — пришел новый гем и puma просто падает при сигнале рестарта :)
Тут кстати логичный вопрос. У уникорна нет потоков, только воркеры, в то время как у пумы — потоки + кластер режим, что означает тоже самое, что и у юникорна. Тоесть вы сравнивали производительность 8 workers unicorns vs 8 puma cluster mode без тредов внутри каждого? Поскольку только так тестирование будет приближено к реальности тестирования самого веб сервера. Ведь puma выиграет, поскольку из коробки один демон создает 16 тредов, что уже дает фору (но и создает проблемы в MRI).
Странно, но мы всегда находили и исправляли утечку памяти. Вариант unicorn-worker-killer уже если вообще команда не может с этим справится (хотя мы monit для этого использовали, что бы следить за памятью — он сразу и писал письмо, что воркер пришлось перегрузить). Но это точно не решает проблему с утечками.
Здесь опять прошу помощи гуру. Объясните, почему при LEFT JOIN и достаточном work_mem, использование Merge Left Join более затратно, чем Hash Left Join?
Hash Left Join отлично работает, если с одной из сторон JOIN выбирается небольшой кусок данных (помещается в work_mem), поскольку можно построить хэш-таблицу и пробежатся по ней при мердже данных. Единственная цель хэш-таблицы является деятельность в качестве временной структуры в памяти, чтобы избежать чтения одной из таблиц множество раз во время JOIN операции :)
Merge Left Join просто собирает отсортированные списки в один. При этом оба списка должны быть отсортированы по предикатам объединения (в вашем случае по foo.c1 и bar.c1). Поэтому так важны индексы на эти поля :)
Ну а кто будет эффективнее — я думаю и так понятно :)
Первый и второй пункт в моем коментарии четко говорят, что такое costs: «оценки времени узла, как ожидается, займет при чтении данных», один юнит в основном: время чтения 8kb данных при использовании seq_page_cost. Понятное дело, что он разный при выборе другого плана выполнения:
seq_page_cost — 1.00 — единица
random_page_cost — 4.00 — cost увеличился, поскольку планер берет в 4 раза больше на операцию, но единица измерения осталась та же
cpu_tuple_cost — 0.01 — в 100 раз быстрее seq_page_cost
cpu_operator_cost — 0.0025 — в 400 раз быстрее seq_page_cost
cpu_index_tuple_cost — 0.005 — в 1000 раз быстрее seq_page_cost
O RLY?
Так сойдет пояснение: формула на latex вписана в url?
upstream prodpuma { server unix:/.../shared/tmp/sockets/puma.sock fail_timeout=0; }Puma:
Zero downtime:
desc 'Restart puma (phased restart)' task :phased_restart, :roles => lambda { puma_role }, :on_no_matching_servers => :continue do run "cd #{current_path} && #{pumactl_cmd} -S #{state_path} phased-restart" endHash Left Join отлично работает, если с одной из сторон JOIN выбирается небольшой кусок данных (помещается в work_mem), поскольку можно построить хэш-таблицу и пробежатся по ней при мердже данных. Единственная цель хэш-таблицы является деятельность в качестве временной структуры в памяти, чтобы избежать чтения одной из таблиц множество раз во время JOIN операции :)
Merge Left Join просто собирает отсортированные списки в один. При этом оба списка должны быть отсортированы по предикатам объединения (в вашем случае по foo.c1 и bar.c1). Поэтому так важны индексы на эти поля :)
Ну а кто будет эффективнее — я думаю и так понятно :)
seq_page_cost — 1.00 — единица
random_page_cost — 4.00 — cost увеличился, поскольку планер берет в 4 раза больше на операцию, но единица измерения осталась та же
cpu_tuple_cost — 0.01 — в 100 раз быстрее seq_page_cost
cpu_operator_cost — 0.0025 — в 400 раз быстрее seq_page_cost
cpu_index_tuple_cost — 0.005 — в 1000 раз быстрее seq_page_cost
Везде говорится про время чтения с диска.
Если только он запросы делает не в вакууме. Это понятие граничит со временем. Вот что нужно знать про cost:
В байтах.
Статья слишком простая. Нет не про типа scans (Index Scan, Index Only Scan, Bitmap Index Scan), не про типы Jons и сортировок при чтении EXPLAIN.