> 10 Гбитный интерфейс между машинками, машинки в одном свитче
Тестирование в локальной сети с реальным миром немного отличается.
> А что, ваш сервис держит 100К запросов в секунду при 10-килобайтных запросах?
Нет, не держит, а создает (все эти параметры меняются). Один из наших продуктов — сервис для нагрузочного тестирования.
> Еще, паралельные юзеры != параллельные запросы. У юзеров есть еще think time между запросами.
Не знаю как у Танка, у нас это настраивается. По умолчанию = 0 (тоесть не «засыпать»). Я говорил про такой виде теста, когда нет think time.
> 50 К ядер на 50 К клиентов тоже не нужно, потому что клиент не требует постоянной работы проца
Если он не засыпает — то требует.
> Ну и не надо забывать, что с противоположной стороны провода тоже не магический кристалл, а земная машинка с процессором, памятью и дисками. И ваши клиенты, сколько бы их ни было, встанут в очередь для того, чтобы пролезть через провод (один).
Многие наши клиенты тестируют и свои системы, которые держат и 1 000 000 клиентов. Многие достигают этого через DNS записи (DNS Round Robin, Geolocation Routing Policy). Мы позволяет им тестировать с разных регионов — так тест похож более на реальный.
Не буду спорить по поводу Танка, но на одной машине я пока не верю, что можно сделать высоконагруженное тестирование (хотя понятие «высоконагруженное» у каждого инженера разное).
Это просто запросы? А параллельных клиентов сколько, которые посылают запросы? Ну и 100000 * 10 КБ POST body ~ 1 Гигабайт в секунду. Утилита могла просто тестировать свою нагрузку.
Я не спорю, может Танк и крут, но пока я не видел утилиты, что может выжать более 50К параллельных клиентов (которые посылают запросы независимо) на одной машине. Да еще и условия самой машины должны быть оптимальны (50К ядерной машины я не видел, а значит и параллельность этих клиентов минимальна — ограничена в CPU + Network)
ЗЫ по докам 30000 эго предел в параллельных юзерах на тест
Как минимум упретесь в сеть или количество одновременно открытых сокетов (65535 максимально, из них 65000 может и получится взять). В конце концов нагрузочное тестирование больших обьемов начнет показывать упирание в ресурсы машины, на которой ведется тестирование, а не ресурс, который Вы тестируете. А это не, что нам нужно измерять.
При разработки сервиса по тестированию именно разбиение теста на мелкие фрагменты (100 клиентов на 1000 машин) давало правильные цифры нагрузки на ресурс (только сбор и агрегация данной информации — это отдельная проблема). Но это я по своему опыту сужу.
# Value Class Type
# -------------------------------------
# "foo" String string
# new String("foo") String object
# 1.2 Number number
# new Number(1.2) Number object
# true Boolean boolean
# new Boolean(true) Boolean object
# new Date() Date object
# new Error() Error object
# [1,2,3] Array object
# new Array(1, 2, 3) Array object
# new Function("") Function function
# /abc/g RegExp object
# new RegExp("meow") RegExp object
# {} Object object
# new Object() Object object
Да, тут будет получше для композитного. Но если рассмотреть запрос чуток посложнее «WHERE a = 5 AND b >= 42 AND c < 77», то композитный не даст огромной скорости (на больших данных), чем отдельные. В официальной документации показан пример и причина данного поведения: www.postgresql.org/docs/devel/static/indexes-multicolumn.html
Я бы не сказал, что разница большая в алгоритмах. С одним (составным) индексом — Btree Index Scan, с N+1 — Bitmap Index Scan, что просто оптимизация Btree Index Scan: вместо того, чтобы зразу идти за данными по первому индексу, но выбирает все индексы по условию, сортирует в битмап структуре, и только потом идет за данными.
Отдельные индексы дают хорошую производительность для SELECT на больших данных, но при этом INSERT/UPDATE/DELETE немного проседает (нужно перестроить N+1 индекса, вместо одного композитного). Композитный экономит место на диске (опять же один индекс против N+1).
В примере я написал, что с помощью двух раздельных вы не сможете гарантировать уникальность по двум/трем/более полям — одна из основных причин создания такого индекса (выборка конечно тоже не маловажна).
Разницы нет (разве что составным не используется для условий, где выбирается только одно поле). Например, иногда нужны отдельно индексы на каждое поле (если в where усчаствует только один) + составной с уникальностью для целостности данных (связь has-many-to-many). Пример: связь таблиц users и companies через companies_users, которая содержит company_id и user_id поля (нельзя допускать, чтобы [company_id, user_id] повторялись)
# CREATE INDEX index_companies_users_on_company_id ON companies_users USING btree (company_id);
# CREATE INDEX index_companies_users_on_user_id ON companies_users USING btree (user_id);
# CREATE UNIQUE INDEX index_companies_users_on_company_id_and_user_id ON companies_users USING btree (company_id, user_id);
Для Slack и Hipchat взята статистика с сервисов, что сводят аптайм сервиса в целом: веб морда, протокол, поисковый движок, прочее. Для Kato взят pingdom только по веб морде. Я сам поддерживаю пару сервисов, и там аптайм в Pingdom 100% каждый месяц, в то время как, например, SMTP сервер (сервис предоставляет это как сервис) не дотягивает до 100% uptime.
Зато появилась другая проблема: мастер может упасть, по причине быстрого заполнения жесткого диска (если хоть один из слейвов не подняли вовремя, или даже просто не заметили, что он упал) :)
В основном мониторим через парсинг логов, но такой подход тоже подойдет. Такую статистику нужно куда то собирать на график, что бы было видно в какие пики что происходит с базой.
Как и любой повар, сначала нужно узнать: «Вам кластер с чем подавать?». Я имею ввиду, что для кластера есть много разных решений :) Добавлять все в одну поваренную книгу будет трудозатратно.
Дискуссия будет длительная. Просто хочу в конце добавить. Robert Haas два года назад писал (еще до перехода PostgreSQL на nmap), что выдавали «львиную» долю памяти (shared_buffers), что давало хорошую производительность rhaas.blogspot.com/2012/03/tuning-sharedbuffers-and-walbuffers.html (у EnterpriseDB достаточно клиентов с PostgreSQL для таких исследований). Так что 40% точно не предел.
effective_cache_size — это размер файлового кеша, shared_buffers — размер shared memory. effective_cache_size используется для построения плана запроса (помещаются ли данные запроса в эту память? использовать агресивный план или придется делать sequence scan в таблице на фаловой системе?).
Как вы взялись писать рекомендации по тюнингу не зная механизма выделения памяти в постгресе я вообще не понимаю.
Странно, я пишу про одно, вы — про другое. С чего вы решили о моей не компетентности — не понятно. Вы просто пытаетесь мне что то доказать, я просто не пойму что. Возьмите параграф из книги где по вашему написано не верно, проведите исправление и пришлите пул реквест.
Тестирование в локальной сети с реальным миром немного отличается.
> А что, ваш сервис держит 100К запросов в секунду при 10-килобайтных запросах?
Нет, не держит, а создает (все эти параметры меняются). Один из наших продуктов — сервис для нагрузочного тестирования.
> Еще, паралельные юзеры != параллельные запросы. У юзеров есть еще think time между запросами.
Не знаю как у Танка, у нас это настраивается. По умолчанию = 0 (тоесть не «засыпать»). Я говорил про такой виде теста, когда нет think time.
> 50 К ядер на 50 К клиентов тоже не нужно, потому что клиент не требует постоянной работы проца
Если он не засыпает — то требует.
> Ну и не надо забывать, что с противоположной стороны провода тоже не магический кристалл, а земная машинка с процессором, памятью и дисками. И ваши клиенты, сколько бы их ни было, встанут в очередь для того, чтобы пролезть через провод (один).
Многие наши клиенты тестируют и свои системы, которые держат и 1 000 000 клиентов. Многие достигают этого через DNS записи (DNS Round Robin, Geolocation Routing Policy). Мы позволяет им тестировать с разных регионов — так тест похож более на реальный.
Не буду спорить по поводу Танка, но на одной машине я пока не верю, что можно сделать высоконагруженное тестирование (хотя понятие «высоконагруженное» у каждого инженера разное).
Это просто запросы? А параллельных клиентов сколько, которые посылают запросы? Ну и 100000 * 10 КБ POST body ~ 1 Гигабайт в секунду. Утилита могла просто тестировать свою нагрузку.
Я не спорю, может Танк и крут, но пока я не видел утилиты, что может выжать более 50К параллельных клиентов (которые посылают запросы независимо) на одной машине. Да еще и условия самой машины должны быть оптимальны (50К ядерной машины я не видел, а значит и параллельность этих клиентов минимальна — ограничена в CPU + Network)
ЗЫ по докам 30000 эго предел в параллельных юзерах на тест
При разработки сервиса по тестированию именно разбиение теста на мелкие фрагменты (100 клиентов на 1000 машин) давало правильные цифры нагрузки на ресурс (только сбор и агрегация данной информации — это отдельная проблема). Но это я по своему опыту сужу.
Отдельные индексы дают хорошую производительность для SELECT на больших данных, но при этом INSERT/UPDATE/DELETE немного проседает (нужно перестроить N+1 индекса, вместо одного композитного). Композитный экономит место на диске (опять же один индекс против N+1).
В примере я написал, что с помощью двух раздельных вы не сможете гарантировать уникальность по двум/трем/более полям — одна из основных причин создания такого индекса (выборка конечно тоже не маловажна).
pgtune.leopard.in.ua/
Пользуйтесь на здоровье.
Для Slack и Hipchat взята статистика с сервисов, что сводят аптайм сервиса в целом: веб морда, протокол, поисковый движок, прочее. Для Kato взят pingdom только по веб морде. Я сам поддерживаю пару сервисов, и там аптайм в Pingdom 100% каждый месяц, в то время как, например, SMTP сервер (сервис предоставляет это как сервис) не дотягивает до 100% uptime.
А это тогда что? monosnap.com/image/IBcPv3rPzBNTmpfeBwJ8dsjyqOhbdt
Странно, я пишу про одно, вы — про другое. С чего вы решили о моей не компетентности — не понятно. Вы просто пытаетесь мне что то доказать, я просто не пойму что. Возьмите параграф из книги где по вашему написано не верно, проведите исправление и пришлите пул реквест.