Тогда не трогайте настройки мастера кроме как max_wal_senders (если был выключен) (для basebackup необходимо минимум 2 коннекта). Ну и чуть-чуть wal_keep_segments всё-таки можно поднять.
По-умолчанию мастер не будет дожидаться реплику. Если мастеру хочется удалить wal - он их удалит как ни в чём не бывало. Если реплика этот wal не прочитала ещё - то получит потом отлуп и надо будет pg_basebackup делать заново. (для изменения этого поведения как раз replication slots и появились)
pg_basebackup -X stream открывает два соединения: по одному копирует базу, по второму подписывается на все новые wal как рядовая реплика. Поэтому во время его работы мастер работает как ни в чём не бывало и удаляет wal как обычно. А вот на реплике wal будут копиться. И стартовать реплика может немного не сразу, пока все эти wal проигрывает. Неприятный момент - за новыми wal к мастеру реплика пойдёт только когда разгребёт все локально записанные wal.
В общем, делается в screen pg_basebackup с ключом --progress, когда он доработал - открывается в другой консоли tail -f лога будущей реплики, запускается реплика и ждём ready to accept connections и starting streaming. Если посыпались ошибки wal segment already removed - стопаем реплику, на мастере поднимаем keep segments и пробуем налить реплику ещё раз. (у нас в dataegret обычно изначально keep segments задран)
21 секунду работали, 508 секунд ждали диски. Естественно если сюда добавлять ещё конкурентной нагрузки - будет только хуже.
explain видите? Глядя на него мысли повесить индекс-другой не возникает? Нет? А почему?
Моя рабочая гипотеза - у вас медленные механические диски и достаточно данных чтобы не помещаться в памяти. В таких условиях один запрос работающий 2 минуты в 10 потоков выполняться час может вполне. Потому что random io на механике - это всегда больно.
Поскольку вы отказываетесь ответить на мои вопросы - ничем больше помочь не могу. Если моя гипотеза верна - в один поток последовательно будет быстрее работать.
sql знаю на уровне запросов, по мне так больше знать и не нужно
explain это уровень именно запроса. И его вы как разработчик понимать должны. Потому что непосредственно работаете с базой. Тем более поскольку ДБА у вас в команде нет, который будет по рукам бить за совершение глупостей.
yuharu, как postgresql DBA поясняю: shared_buffers - это такая настройка postgresql. Чтобы не гадать, где та переопределяется и с чем база запущена - лучше про неё спросить саму запущенную базу запросом show shared_buffers. Explain - это explain. Как (судя по вопросу) разработчик работающий с СУБД вы должны знать что это. Дополнительные параметры за explain - это дополнительные параметры explain. Лучше бы разработчики о них тоже знали, ну да ладно. Это то, по чему можно много полезного и увлекательного узнать о проблемных запросах. track_io_timing - настройка, добавляющая ещё полезных данных в секцию buffers у explain. А больше ничего про базу я ещё не спросил, всё остальное обычные системные метрики которые надо узнать у сисадмина.
Если не хотите разбираться в работе базы - вам дорога во фриланс или, например, к нам в dataegret за коммерческой поддержкой (ссылка у меня в профиле есть).
Какие диски? Добавьте в вопрос графики мониторинга с io util и iops. Или штук 5-10 листингов iostat -x 1 при выполняемых запросах.
Плюс сколько памяти всего (free -h) и сколько выделено shared_buffers
mrWan, и чем же это вам упростило поиск ошибки? Вы это написали и вы этим не смогли воспользоваться никак. Вы даже не посмотрели, что вам возвращает функция, иначе ваш вопрос звучал бы совсем иначе.
В рабочем режиме тем более. Функция, выдающая в зависимости от фазы луны строку с результирующими данными или строку с описанием ошибки - это к проблемам.
longclaps, именно только для myisam. Для мультиверсионного транзакционника innodb вопрос "сколько у тебя строк" не имеет смысла вообще. Имеет смысл "сколько версий строк видит моя транзакция". И без проверки каждой строки на видимость в конкретной транзакции это не узнать. В статистике же хранится приблизительное число строк.
TrueNinja, а кто сказал, что в блоке питания нет проблемы? Симптоматика не характерная и только, а причиной быть по-прежнему может.
Температуры в норме - это в числах сколько? Раздельно по каждому ядру CPU, GPU и VRM
Думаю в этом контексте максимальным ограничением поддерживаемой памяти можно пренебречь
Это если не стоит выбор между двумя конкретными конфигурациями: с 32гб или 64 гб. В вопросе именно так описано, поэтому я не про максимальных поддерживаемый объём.
Базе нужна преимущественно память (но и ядра тоже), веб-серверу - в зависимости от качества написанного кода. Но параллелится нагрузка этого профиля хорошо.
Проглядел в тегах - похоже речь о VPS. Выясните у хостера - выделяются статично ядра физические или как повезёт и можно получить псевдоядра HT? И раз это VPS - то сколько в итоге дают вам ядер?
primary key в принципе не может быть null. auto_increment не может быть отдельно от первичного или уникального ключа. Подцепитесь штатным консольным клиентом и проверьте данные и show create table в консоли.
synchronous_commit в 8.4 уже был https://www.postgresql.org/docs/8.4/static/runtime...
Но перед выключением внимательно прочитайте что именно эта гайка делает. tradeoff между производительностью и риском потери последних коммитов при аварии.
huge pages - это к параметрам операционной системы. До 9.2 включительно можно было извращаться с libhugetlbfs. А вот начиная с какой версии можно было извращаться - хз. Впрочем до 32гб памяти можно не заморачиваться.
shared_buffers 32мб - это кошмар. Годится только если вы на каком-нибудь утюге запустились где всего 128-256мб памяти.
Чтобы понимать масштабы - postgresql будет обрабатывать данные только в shared_buffers. Чтобы сходить за данными в индекс - надо прочитать какие-то части индекса в shared_buffers (минимум 1 страничку корня btree, дальше как получится по запросу). Чтобы по полученным из индекса ctid сходить за данными - надо идти в таблицу, читать страницы в shared_buffers. И постоянно вытеснять другие страницы из shared_buffers. Потому что в 32мб можно поместить всего 32мб/8кб = 4096 страниц. Картину немного исправляет то, что postgresql использует системный файловый кеш. Но ходить настолько интенсивно в файловый кеш штука не бесплатная.
Наша в dataegret обычная рекомендация - отдельная машина только под базу, 25% RAM под shared_buffers. Т.е. никаких приложений на той же машине - иначе невозможно контролировать ресурсы. Какой-нибудь PHP случайно откушал на 20гб памяти и база в свопе - это из реальной практики. Если база влезает в память - то можно до 75% памяти отдать под shared_buffers.
Индексы - если кратко то всё сложнее. Ненужными индексами можно сделать хуже (особенно в зависимости от интенсивности записи). Писать ещё одно сочинение по тому как проставлять индексы настроения нет. Есть замечательный материал здесь: use-the-index-luke.com
Надо учитывать, что гайки и fsync и synchronous_commit - это для операций записи. Если много читаем с медленных дисков - они никак не повлияют на происходящее.
Что вы сделали для того, чтобы изменённые переменные окружения устанавливались заново при следующей авторизации пользователя? В PATH очевидно отсутствует место куда вы поставили бинарники базы.
