Т
S B
у вас нет никакой проблемы, всё работает как и задумано
ну чтобы не было таймаутов. увеличить default_pool_size?
Size: a a a
2020 June 15
SB
если увеличить default_pool_size то вы сможете открывать больше одновременных транзакций, если это то что вам нужно, то ответ — да :-)
SB
у вас кстати в логе вообще нет запросов к базе, вы уверены что этот тот лог?
Т
S B
если увеличить default_pool_size то вы сможете открывать больше одновременных транзакций, если это то что вам нужно, то ответ — да :-)
стоит кластер на 32 процесса в каждом из которых очень много паралельных запросов
SB
ну а у вас в логе написано: «запросов к базе за последнюю минуту — 0 штук»
Т
S B
ну а у вас в логе написано: «запросов к базе за последнюю минуту — 0 штук»
не всегда
Т
SB
2 запроса в минуту как то не похоже на «кластер на 32 процесса в каждом из которых очень много паралельных запросов» согласитесь :-)
YS
я понял как это работает.
Я не хочу использовать timestamptz, т.к. провайдер БД для приложения будет отдавать его как ZonedDateTime с зоной текущего подключения. А я хотел бы, чтобы семантика колонки была одной и той же - момент абсолютного времени (Instant), чтобы у коллег не возникало и малейшего подозрения, что время - уже в нужной таймзоне и чтобы система типов приложения это подозрение моментально опровергала при попытке его сделать =)
добавлять at utc в скриптах - более вербозно, но эту цену я готов взять, ибо сырого sql в проекте значительно меньше, чем ORM-ного кода
Я не хочу использовать timestamptz, т.к. провайдер БД для приложения будет отдавать его как ZonedDateTime с зоной текущего подключения. А я хотел бы, чтобы семантика колонки была одной и той же - момент абсолютного времени (Instant), чтобы у коллег не возникало и малейшего подозрения, что время - уже в нужной таймзоне и чтобы система типов приложения это подозрение моментально опровергала при попытке его сделать =)
добавлять at utc в скриптах - более вербозно, но эту цену я готов взять, ибо сырого sql в проекте значительно меньше, чем ORM-ного кода
См. https://t.me/pgsql/232823 (почему-то не процитировалось).
GB
Yaroslav Schekin
См. https://t.me/pgsql/232823 (почему-то не процитировалось).
увидел, спасибо. Сейчас пишу скрипт-эксперимент, чтобы обнаружить, сколько ошибок я допущу в операциях, которые кажутся имеющими смысл для приложения. Отвечу как завершу
МВ
#вакансия #DBA #АдминистраторБД #PostgreSQL #MySQL #MongoDB
Добрый день.
Компания IBS, лидер в области IT-консалтинга и разработки, приглашает в свою команду Администратора БД PostgreSQL/ MySQL
ВАКАНСИЯ: Администратор БД PostgreSQL/ MySQL
Компания: IBS - IT-консалтинг
Формат работы: работа в офисе (локация – Москва)
Занятость: полная
Зарплатная вилка: от 120 000 – 250 000
Обязанности:
1. Настройка репликаций БД, резервного копирования и восстановления данных.
2. Анализ проблем производительности СУБД и выдача рекомендаций по повышению эффективности работы приложений.
3. Реализация политик резервного копирования БД, создание и сопровождение резервных БД.
4. Построение и управление КХД (DWH) на базе GreenPlum или ClickHouse.
5. Участие в разработке и поддержке БД внутренних сервисов.
6. Анализ возникновения нестандартных ситуаций на СУБД
7. Быть готовым изучать и внедрять новые технологии, методологии, best practices.
8. Работа в команде с разработчиками, тестировщиками и смежными подразделениями администраторов.
9. Ведение технической документации
Требуемые компетенции:
1. Опыт работы с высоконагруженными СУБД.
2. Экспертное знание СУБД: MySQL и PostgreSQL.
3. Опыт работы с MongoDB.
4. Приветствуется опыт использования систем управления конфигурацией: ansible, puppet.
5. Опыт разбора сложных инфраструктурных инцидентов.
6. Уверенное владение bash.
7. Понимание принципов построения архитектуры высоконагруженных, масштабируемых и кластеров СУБД настройки необходимых служб.
8. Умение разбираться в новых системах, искать гибкий подход к реализации задач, самостоятельно решать задачи в оговоренные сроки
Мы предлагаем:
Стабильный доход: оклад + премии + проектные бонусы.
Обучение и сертификацию.
Индивидуальный план развития в рамках ежегодной аттестации.
Гибкую схему профессионального и карьерного роста.
Добровольное медицинское страхование для сотрудника и его детей, программы льготного кредитования, фитнес-центры.
Для связи:
e-mail: MSVorobeva@IBS.RU
Добрый день.
Компания IBS, лидер в области IT-консалтинга и разработки, приглашает в свою команду Администратора БД PostgreSQL/ MySQL
ВАКАНСИЯ: Администратор БД PostgreSQL/ MySQL
Компания: IBS - IT-консалтинг
Формат работы: работа в офисе (локация – Москва)
Занятость: полная
Зарплатная вилка: от 120 000 – 250 000
Обязанности:
1. Настройка репликаций БД, резервного копирования и восстановления данных.
2. Анализ проблем производительности СУБД и выдача рекомендаций по повышению эффективности работы приложений.
3. Реализация политик резервного копирования БД, создание и сопровождение резервных БД.
4. Построение и управление КХД (DWH) на базе GreenPlum или ClickHouse.
5. Участие в разработке и поддержке БД внутренних сервисов.
6. Анализ возникновения нестандартных ситуаций на СУБД
7. Быть готовым изучать и внедрять новые технологии, методологии, best practices.
8. Работа в команде с разработчиками, тестировщиками и смежными подразделениями администраторов.
9. Ведение технической документации
Требуемые компетенции:
1. Опыт работы с высоконагруженными СУБД.
2. Экспертное знание СУБД: MySQL и PostgreSQL.
3. Опыт работы с MongoDB.
4. Приветствуется опыт использования систем управления конфигурацией: ansible, puppet.
5. Опыт разбора сложных инфраструктурных инцидентов.
6. Уверенное владение bash.
7. Понимание принципов построения архитектуры высоконагруженных, масштабируемых и кластеров СУБД настройки необходимых служб.
8. Умение разбираться в новых системах, искать гибкий подход к реализации задач, самостоятельно решать задачи в оговоренные сроки
Мы предлагаем:
Стабильный доход: оклад + премии + проектные бонусы.
Обучение и сертификацию.
Индивидуальный план развития в рамках ежегодной аттестации.
Гибкую схему профессионального и карьерного роста.
Добровольное медицинское страхование для сотрудника и его детей, программы льготного кредитования, фитнес-центры.
Для связи:
e-mail: MSVorobeva@IBS.RU
Т
S B
2 запроса в минуту как то не похоже на «кластер на 32 процесса в каждом из которых очень много паралельных запросов» согласитесь :-)
просто приложение пока в прод не пустили ещё
SB
просто приложение пока в прод не пустили ещё
то что вы говорите (query_wait_timeout) — не согласуется с логом pgbouncer который вы показываете, у вас в логе явно меньше 32 одновременных запросов и нет ошибок query_wait_timeout
SB
возможно вы настраиваете один баунсер, а смотрите лог от другого, я так один раз перепутал =)
GB
Yaroslav Schekin
> Я не хочу использовать timestamptz
А зря не хотите. Дело в том, что timestamptz в PostgreSQL — это default type для этой категории типов, естественно.
Поэтому все преобразования и функции по умолчанию "тянет" в эту сторону. Т.е. обходиться без него можно, но ни разу не ошибиться (и эти ошибки будут совсем не очевидны!) не так-то просто.
> т.к. провайдер БД для приложения будет отдавать его как ZonedDateTime с зоной текущего подключения
Хмм... то есть? Что это за тип в postgres-овских терминах? Или, если это текст, как выглядят эти константы?
> А я хотел бы, чтобы семантика колонки была одной и той же - момент абсолютного времени (Instant),
И это как раз timestamptz!
> что время - уже в нужной таймзоне
В нормальных клиентах наличие части вроде "+07" в конце каждого значения толсто намекает, что это timestamptz. ;)
> но эту цену я готов взять
А заплатить можете ещё и другую — ошибками.
А зря не хотите. Дело в том, что timestamptz в PostgreSQL — это default type для этой категории типов, естественно.
Поэтому все преобразования и функции по умолчанию "тянет" в эту сторону. Т.е. обходиться без него можно, но ни разу не ошибиться (и эти ошибки будут совсем не очевидны!) не так-то просто.
> т.к. провайдер БД для приложения будет отдавать его как ZonedDateTime с зоной текущего подключения
Хмм... то есть? Что это за тип в postgres-овских терминах? Или, если это текст, как выглядят эти константы?
> А я хотел бы, чтобы семантика колонки была одной и той же - момент абсолютного времени (Instant),
И это как раз timestamptz!
> что время - уже в нужной таймзоне
В нормальных клиентах наличие части вроде "+07" в конце каждого значения толсто намекает, что это timestamptz. ;)
> но эту цену я готов взять
А заплатить можете ещё и другую — ошибками.
1. Навскидку из того, что смог придумать, нигде не ошибся, файл прилагаю следующим сообщением - это слишком длинное для комментария к файлу.
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
GB
1. Навскидку из того, что смог придумать, нигде не ошибся, файл прилагаю следующим сообщением - это слишком длинное для комментария к файлу.
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
GB
1. Навскидку из того, что смог придумать, нигде не ошибся, файл прилагаю следующим сообщением - это слишком длинное для комментария к файлу.
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
попробовал timestamptz, логика отработала так же, в выводе клиент рисует локальное клиентской машине время, что очень не удобно (редактирование через UI так же ожидает ввода локального времени). Последнее может вести к ошибкам при ручном заполнении данных через UI, которым коллеги иногда пользуются. К сожалению, проблема - в драйвере jdbc, и для нормальной работы с UI клиентом необходимо менять настройки сессии, чему придётся учить UI-юзеров. Кажется, всё-таки timestamp пойдёт лучше - он со всех сторон выглядит безопаснее. По крайней мере, на сделанной мной выборке операций. Может, я не учёл какой-то операции, которая так же вероятно может встретиться в коде и которая приведёт к ошибкам при работе с таймзонами
YS
1. Навскидку из того, что смог придумать, нигде не ошибся, файл прилагаю следующим сообщением - это слишком длинное для комментария к файлу.
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
2. У меня тут фактическая ошибка, и можно маппить и в Instant (посмотрел сорцы).
Отвечая на вопросы: ZonedDateTime (в Java (вроде) 5+ версии и в .NET с библиотекой NodaTime) - timestamptz (в вашем определении - "абсолютное время") + timezone, где timezone может быть идентификатором из tzdb (могут быть другие источники, но они мне не интересны). Провайдер маппит его, используя таймзону соединения, что не будет очевидно тем, кто не знает, как в ПГ работают таймзоны. Instant - более подходящий вариант, т.к. он представляет timestamptz (в том же определении) без указания таймзоны.
3. В связи с фактической ошибкой выше - согласен с вами. Если бы не она, то маппинг во время с бесполезной таймзоной на стороне провайдера делал бы семантику неконсистентной (провайдер говорит, что таймзона есть, по факту - её нет)
4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол. В бинарном, насколько я знаю, указания на этот оффсет нет; по крайней мере в рассматриваемом провайдере читаемое значение используется как utc-шное время (я не изучал протоколы ПГ)
5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Исходя из того что провайдер позволяет маппить timestamptz в Instant, буду использовать timestamptz - так и семантика будет консистентна, и, наверное, ошибок будет меньше (сейчас опробую тот же файл на timestamptz)
До следующего пункта — примерно понятно.
> 4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол.
Я имел в виду те, в которых разработчики будут проверять запросы и т.п. (psql, например).
> В бинарном, насколько я знаю, указания на этот оффсет нет;
Ну да, это же just human-readable representation.
> 5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Я их особо не коллекционирую. ;)
> 4. Не соглашусь, что нормальные клиенты будут использовать текстовый протокол.
Я имел в виду те, в которых разработчики будут проверять запросы и т.п. (psql, например).
> В бинарном, насколько я знаю, указания на этот оффсет нет;
Ну да, это же just human-readable representation.
> 5. Можете привести пример какой-нибудь интересной грабли, ради научного интереса?
Я их особо не коллекционирую. ;)
YS
Неплохо для первого раза — Вы "напороли" только в first_3_per_date, на первый взгляд (угадаете, в чём ошибка)? ;)
GB
Yaroslav Schekin
Неплохо для первого раза — Вы "напороли" только в first_3_per_date, на первый взгляд (угадаете, в чём ошибка)? ;)
пересмотрел его вывод, всё выглядит корректно - первые три записи по каждой дате отправления (локальной)