S
Всё понял, т.е. в принципе это нормальное поведение при некоторых обстоятельствах. Большое спасибо :)
Size: a a a
2020 May 21
YS
просто хочу понять, это нормально или нет что 1 очень тяжелый селект выжирает диск на read на 100%?
А почему нет? Вы диск (и прочее "железо") купили не для того, чтобы не утруждать их и сдувать с них пылинки, я надеюсь? ;)
S
Нет конечно)) но я надеялся что есть какие то механизмы ограничений чтобы оно прям на 100% не нагружало и давало соседним запросам жить без проблем)
TS
On RDS you will need to create a new parameter group, set
rds.logical_replication = 1 in it, then make the parameter group the active one. Applying the change requires a database server rebootБольшое спасибо! А это ведь логическая репликация? а не потоковая?
YS
Нет конечно)) но я надеялся что есть какие то механизмы ограничений чтобы оно прям на 100% не нагружало и давало соседним запросам жить без проблем)
Хмм... "соседние" запросы — это другое дело. Тут уже стоит смотреть, что именно происходит (но механизмов ограничения или приоритетов I/O в сервере PostgreSQL нет, насколько я помню).
Тут дело и в том, что если бы оно "давало соседним запросам жить без проблем", то этот запрос выполнялся бы медленнее... а чем он хуже других? ;)
Тут дело и в том, что если бы оно "давало соседним запросам жить без проблем", то этот запрос выполнялся бы медленнее... а чем он хуже других? ;)
S
ну да, логично))
AS
Коллеги, привет!
Перенесли сервер 1С в Hetzner: сервер приложений + сервер баз данных.
Конфигурация железа стала лучше, плюс разнесли приложение отдельно от базы данных.
Однако выполнение фонового задания по перепроведению документов выполняется в раза в 2.5 медленнее и не успевает отработать за ночь.
Кто-нибудь сталкивался с подобной ситуацией?
Если да, как решали?
Перенесли сервер 1С в Hetzner: сервер приложений + сервер баз данных.
Конфигурация железа стала лучше, плюс разнесли приложение отдельно от базы данных.
Однако выполнение фонового задания по перепроведению документов выполняется в раза в 2.5 медленнее и не успевает отработать за ночь.
Кто-нибудь сталкивался с подобной ситуацией?
Если да, как решали?
YS
Alexander Sergienja
Коллеги, привет!
Перенесли сервер 1С в Hetzner: сервер приложений + сервер баз данных.
Конфигурация железа стала лучше, плюс разнесли приложение отдельно от базы данных.
Однако выполнение фонового задания по перепроведению документов выполняется в раза в 2.5 медленнее и не успевает отработать за ночь.
Кто-нибудь сталкивался с подобной ситуацией?
Если да, как решали?
Перенесли сервер 1С в Hetzner: сервер приложений + сервер баз данных.
Конфигурация железа стала лучше, плюс разнесли приложение отдельно от базы данных.
Однако выполнение фонового задания по перепроведению документов выполняется в раза в 2.5 медленнее и не успевает отработать за ночь.
Кто-нибудь сталкивался с подобной ситуацией?
Если да, как решали?
Без конкретной информации (запросов, планов, настроек, железа, нагрузки) / знания контекста тут ничего не скажешь.
Что касается последнего, тут где-то был чат по PostgreSQL+1C (поищите ссылку в истории этого чата, я не помню).
Что касается последнего, тут где-то был чат по PostgreSQL+1C (поищите ссылку в истории этого чата, я не помню).
NS
ну и есть стандартные точки проверки:
для pg - conn pooling
и для хецнера - MTU
для pg - conn pooling
и для хецнера - MTU
AS
Yaroslav Schekin
Без конкретной информации (запросов, планов, настроек, железа, нагрузки) / знания контекста тут ничего не скажешь.
Что касается последнего, тут где-то был чат по PostgreSQL+1C (поищите ссылку в истории этого чата, я не помню).
Что касается последнего, тут где-то был чат по PostgreSQL+1C (поищите ссылку в истории этого чата, я не помню).
Понял, спасибо
РЖ
Ни один пулер с 1С не дружит.
DA
не подскажите почему может не сработать ILIKE
WHERE address ILIKE '%городской%';
не находит записи: "Городской"
WHERE address ILIKE '%городской%';
не находит записи: "Городской"
NS
Роман Жарков
Ни один пулер с 1С не дружит.
звучит странно: pgbouncer в session должен работать без всяких проблем...
YS
Denis Alekseev
не подскажите почему может не сработать ILIKE
WHERE address ILIKE '%городской%';
не находит записи: "Городской"
WHERE address ILIKE '%городской%';
не находит записи: "Городской"
Проблемы с encodings/collations, возможно? Вы это в (корректно настроенном в этом отношении) psql пробовали?
РЖ
звучит странно: pgbouncer в session должен работать без всяких проблем...
1С прямо заявляют, что не поддерживают работу с пулерами.
Внутри она, кстати, сама себе пулер.
Внутри она, кстати, сама себе пулер.
NS
Роман Жарков
1С прямо заявляют, что не поддерживают работу с пулерами.
Внутри она, кстати, сама себе пулер.
Внутри она, кстати, сама себе пулер.
Интересно. Положу в копилку в голове. Всё-таки я от 1с далек, но мало ли пригодится. Спасибо!
AN
Подскажите по одиссею пож-ста, не совсем понимаю что делать дальше - выполнил то что указано на странице продукта: git clone git://github.com/yandex/odyssey.git
cd odyssey
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make после последнего make он выдал postgres@student-VirtualBox:~/odyssey/build$ make
make: *** No targets specified and no makefile found. Stop.
и что теперь с этим со всем делать?
cd odyssey
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make после последнего make он выдал postgres@student-VirtualBox:~/odyssey/build$ make
make: *** No targets specified and no makefile found. Stop.
и что теперь с этим со всем делать?
РЖ
Да вроде без проблем собирался.
G
Denis Alekseev
не подскажите почему может не сработать ILIKE
WHERE address ILIKE '%городской%';
не находит записи: "Городской"
WHERE address ILIKE '%городской%';
не находит записи: "Городской"
Самое банальное из того, с чем я сталкивалась, это не все символы русские... "о" или "с" в базе могут оказаться английскими
А
select now() at time zone 'GMT+3:00';
timezone
----------------------------
2020-05-21 06:34:01.736447
(1 row)
select now()::timestamp at time zone 'GMT+3:00';
timezone
-------------------------------
2020-05-21 12:34:06.638887+00
(1 row)
timezone
----------------------------
2020-05-21 06:34:01.736447
(1 row)
select now()::timestamp at time zone 'GMT+3:00';
timezone
-------------------------------
2020-05-21 12:34:06.638887+00
(1 row)