@pgsql

« Назад

Страница 43 из 1062

Далее »

Kirill

17.06.2016
09:39:29

всегда можно посмотреть вот так select * from pg_settings where name='hot_standby_feedback'; - sighup

Alex

17.06.2016
09:40:28

уже

blkmrkt

17.06.2016
12:48:29

кто-нибудь пользуется NVMe хранилищем для постгреса? можете результаты pg_test_fsync показать?

Коллеги, подскажите как лучше сделать доступный, но не обязательно высоконгаруженный сервер postgres. Сам думаю над вариантом 3 сервера postgres и перед ними pgpool для балансировки. Почти единственный критерий который надо выдержать это большое колво коннектов (порядка 15к)

ого, 15к подключений. у вас наверное что-то серьезно неправильно с архитектурой

Google

Алексей

17.06.2016
12:56:07

это так да.

blkmrkt

17.06.2016
12:57:26

а какой проект если не секрет?

Alex

17.06.2016
12:57:57

а почему сразу проблемы в архитектуре ? может хайлоад ;)

Алексей

17.06.2016
12:59:13

просто есть django приложение которое потихоньку мигрирует в сторону микросервисов. один из демонов растиражирован на несколько хостов. на каждом из хостов работаетпорядока 60 копий демона. на каждом из демонов около 200 ниток. каждая нитка хочет коннект.

blkmrkt

17.06.2016
12:59:47

а почему сразу проблемы в архитектуре ? может хайлоад ;)

если делать правильно, то для такого хайлоада нужно 15к ядер, чтоб задаваться вопросом оптимизации)

Сергей

17.06.2016
12:59:55

хочет постоянный коннект?

Алексей

17.06.2016
13:00:14

к сожалению хочет постоянный.

при этом реально делает ооочень мало выборок.

коллеги занимаются оптимизацией и перекройкой архитектуры. но на это требуется время.

пока же у меня появилась возможность сделать резерв postgres

Phil

17.06.2016
13:01:48

какойто там вроде балансер был

Constantin

17.06.2016
13:01:55

pgbouncer не помогает?

Алексей

17.06.2016
13:02:22

нет pgbouncer в режиме transaction пикает и все портит.

Google

Сергей

17.06.2016
13:02:42

что значит "пикает"?

Constantin

17.06.2016
13:02:44

надо более мелкозернистый режим

если клиент держит долгую транзакцию, то конечно будет портить

Алексей

17.06.2016
13:04:17

нет транзакции очень маленькие.

Constantin

17.06.2016
13:05:27

тогда не понятно, что значит "пикает и портит" :)

Сергей

17.06.2016
13:05:59

вы наверное используете подготовленные запросы?

Алексей

17.06.2016
13:07:47

вы наверное используете подготовленные запросы?

да.

Сергей

17.06.2016
13:08:28

если откажетесь от них в пользу функций, то сможете без проблем использовать pgbouncer в режиме transaction

я так работаю

Алексей

17.06.2016
13:09:41

этот вариант у нас тоже в проработке.

Сергей

17.06.2016
13:10:50

на мой взгляд наиболее работоспособный вариант. на клиенте если и есть транзакции, то маленькие, никаких обращений к таблицам напрямую, только через функции. и будет вам счастье

Алексей

17.06.2016
13:11:10

функции всмысле в db ?

blkmrkt

17.06.2016
13:11:12

может у кого-нибудь есть готовая функция на pgSQL, которая делает deep diff JSON объекта?

Сергей

17.06.2016
13:11:38

что значит deep ?

blkmrkt

17.06.2016
13:12:05

что значит deep ?

ну чтоб не первые ключи сверяла, а все

что значит deep ?

https://github.com/benjamine/jsondiffpatch вот этот функционал хотелось бы внутрь postgres перенести

Сергей

17.06.2016
13:17:15

попробуйте посмотреть в сторону использования языка plv8 (jаvascript) https://github.com/plv8/plv8 наверное получится тогда перенести алгоритм почти в чистом виде.

blkmrkt

17.06.2016
13:20:21

попробуйте посмотреть в сторону использования языка plv8 (jаvascript) https://github.com/plv8/plv8 наверное получится тогда перенести алгоритм почти в чистом виде.

ого, спасибо! но на SO пишут что plv8 не интегрирован с самим постгресом, и может работать медленнее чем plpgsql. большая ли разница в производительности на практике?

Сергей

17.06.2016
13:23:50

я сам не пробовал, но вот другие ( http://postgresql.leopard.in.ua/html/#%D1%81%D0%BA%D0%BE%D1%80%D0%BE%D1%81%D1%82%D1%8C-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B ) пишут, что например математика на plv8 примерно в 270 раз быстрее

Kirill

17.06.2016
13:23:50

они разные, очень. v8 - это приложение внутри постгреса которое, по сути , работает с такимиже соединениями если нужно работать с бд. По скорости работы как языка оно гораздо быстрее

Google

Kirill

17.06.2016
13:31:21

просто есть django приложение которое потихоньку мигрирует в сторону микросервисов. один из демонов растиражирован на несколько хостов. на каждом из хостов работаетпорядока 60 копий демона. на каждом из демонов около 200 ниток. каждая нитка хочет коннект.

предложите им "по собственному", нет, ну правда, что за... )

Алексей

17.06.2016
13:31:51

эм не за что.

Kirill

17.06.2016
13:32:36

за одну тысачу двести соединений к БД с одной машины

Алексей

17.06.2016
13:32:43

направление в сторону микросервисов правильное. текущее положение нет. и ребята со временем исправятся.

к тому же такое поведение есть только для действительно большого инстанса.

на более мелких инстансов демонов надо сильно меньше и коннектов сильно меньше.

Kirill

17.06.2016
13:35:40

вот как раз тут "размер не имеет значения"

Алексей

17.06.2016
13:36:40

я соглашусь что нормальное поведение это api proxy перед базой. но это пока требует значительного изменения архитектуры.

Andrey

17.06.2016
13:36:43

кто-нибудь пользуется NVMe хранилищем для постгреса? можете результаты pg_test_fsync показать?

https://habrahabr.ru/company/hpe/blog/282395/

Алексей

17.06.2016
13:36:58

в некоторйо перспективе стоит вопрос. а нужен ли postgres или оставить только mongodb

Kirill

17.06.2016
13:37:15

я соглашусь что нормальное поведение это api proxy перед базой. но это пока требует значительного изменения архитектуры.

нормально, в данном случае, это использовать пул соединений внутри приложения

Алексей

17.06.2016
13:37:42

пул соединений не сильно уменьшает требования.

Алексей

17.06.2016
13:38:00

и не решает корреным образом проблемы

Kirill

17.06.2016
13:38:13

в вашем случае это должно быть на порядки

Алексей

17.06.2016
13:38:45

на два. на два порядка. как максимум.

но реально будет с каждого демона не по 200 соединений а по 20

то есть на порядок.

Kirill

17.06.2016
13:39:43

они могут использовать 1 соединение, как вы пишите запросов там не много

Алексей

17.06.2016
13:39:53

1200 соедиенний там где было 12000 так себе уменьшение.

Kirill

17.06.2016
13:40:54

это минус 10800 соединений!!!

Google

Алексей

17.06.2016
13:41:23

эти соедиенения мне сейчас ни к селу ни к городу.

Kirill

17.06.2016
13:41:40

ок

Алексей

17.06.2016
13:42:04

текущая архитектура вполне тянет. вопрос которой меня гложет как заюзать два дополнительных сервера которые мне выделили под резерв бд

Admin

ERROR: S client not available

Kirill

17.06.2016
13:42:46

реплика + бэкап

Алексей

17.06.2016
13:43:35

реплика хорошо. slave

а backup это что ? :)

Alex

17.06.2016
13:43:52

тут человека я думаю скорее лоад балансинг волнует

R/W - R - R

Алексей

17.06.2016
13:44:41

R/W - R - R

ну да.

Kirill

17.06.2016
13:44:44

что там волноваться, запросов у него нет

Алексей

17.06.2016
13:44:56

запросов и правда мало.

меня волнует это с точки зрения operations

я хочу как можно меньше трахаться с postgres в случае когда падает мастер.

Kirill

17.06.2016
13:53:32

упал мастер -> поменяли адрес на pgbouncer -> настраиваете репликацию с нового мастера

Алексей

17.06.2016
13:55:34

мне почему то не нравится концепция при которой мне постоянно надо что то настраивать.

Vadim

17.06.2016
13:56:08

еще же у постгреса библиотечный кэш свой у каждого процесса))

12000 коннектов наверно с однотипными запросами, каждый будет свой план строить?

Kirill

17.06.2016
13:57:41

будет

Алексей

17.06.2016
13:57:44

там prepared почти всё

Google

Kirill

17.06.2016
13:58:05

планы хрянятся в локальной памяти процесса

Алексей

17.06.2016
14:00:49

а есть ли смысл делать не один/два pgpool а делать по одному рядом с каждым из демонов которые хотят коннекты ? и пусть pgpool хранит информации о том кто сейчас мастер или я бред несу ?

Alex

17.06.2016
14:04:02

ну на случай фейла одного из пгпулов вероятно есть

Kirill

17.06.2016
14:07:30

а есть ли смысл делать не один/два pgpool а делать по одному рядом с каждым из демонов которые хотят коннекты ? и пусть pgpool хранит информации о том кто сейчас мастер или я бред несу ?

тут нажно понимать - зачем ? в авито такая схема, но с phbouncer, есть видео, в нем Михаил Тюрин рассказывает почему

Алексей

17.06.2016
14:10:31

https://www.youtube.com/watch?v=2LDAcGZRAEM оно ?

Kirill

17.06.2016
14:11:25

вроде позже было

у них основная проблема в том что php и оно не может держать постоянные конекты, они ходят в локальный pgbouncer через сокет, а тот уже держит соединение до машины с БД и pgbouncer перед ней

как-то так, насколько я помню

Сергей

17.06.2016
14:15:50

вот здесь посомтри https://www.youtube.com/watch?v=3Aox4aNOXGE&list=PL83V-7Vhzqkozq5wkv-LxhmKa_HTLbz3c&index=14

Алексей

17.06.2016
14:24:27

вот здесь посомтри https://www.youtube.com/watch?v=3Aox4aNOXGE&list=PL83V-7Vhzqkozq5wkv-LxhmKa_HTLbz3c&index=14

посмотрю спасибо

[Anonymous]

17.06.2016
16:32:13

300 человек)

blkmrkt