В японском городе Инадзава разгорелся необычный скандал: старший пожарный получил дисциплинарное взыскание после того, как выяснилось, что он систематически принуждал подчинённых играть в настольные игры собственного производства прямо во время несения службы.
Как выяснилось, всё это длилось с июля 2024 по январь 2025 года. Причём инициатива шла не "снизу": сержант сам придумывал игры и, по сути, заставлял коллег участвовать. Делал он их буквально на коленке – писал правила на листах бумаги, вдохновляясь карточными и словесными играми.
Начальник пожарной охраны и руководители приносят извинения
Отказаться было непросто. По словам сотрудников, играть приходилось даже во время перерывов на сон, а тех, кто пытался уклониться, начинали игнорировать. В итоге один из работников сообщил о ситуации руководству. Сам "виновник" объяснил происходящее попыткой "наладить коммуникацию" в коллективе и заявил, что искренне сожалеет.
Масштаб происходящего хорошо иллюстрируют цифры: один из сотрудников провел за настолками в общей сложности 35 часов, включая время, отведенное на сон.
Поскольку они пренебрегали своими обязанностями, пожарных вынуждали фальсифицировать отчеты о работе. Отдельный момент – в этом не было денег. То есть никакого азарта или ставок, просто игры. И именно это сильнее всего удивило пользователей в сети.
Эта небольшая развлекательная зарисовка на тему, как проходила внедрение "нейронки" в нашей корпорации. Надеюсь, это произведение не только развлечёт вас весёлым текстом и весёлыми картинками, но и поможет вам эффективно использовать нейросети в вашей работе. Наша "нейронка" Лиза - очень умная, красивая, добрая, общительная и сообразительная девушка. Надеюсь, знакомство с ней доставит вам удовольствие.
Совещание уже подходило к концу. Ничто не предвещало чего-то интересного.
- Ах, да, чуть было не забыл, - сказал наш генеральный директор Борис Борисович. - Есть ещё одна новость.
Все напряглись. Это был фирменный стиль нашего начальника. Самую важную информацию он сообщал вскользь, как бы, между прочим. Эта информация могла быть и приятной, как повышенная премия или неожиданная материальная помощь. Но вполне могла быть и неприятной, как сокращение штатов или какое-то неожиданное неприятное задание. Неудивительно, что все напряглись в ожидании сюрприза, пытаясь по выражению лица начальника угадать, какого характера будет этот сюрприз.
- У нас новенькая будет работать, - объявил Борис Борисович. - В техническом отделе.
- Разработчица? Кто такая? Молодая? - заинтересовался народ.
- Молодая, но очень перспективная, - объявил Борис Борисович. - Зовут Лиза. Но она не совсем разработчица. Хотя разрабатывать умеет очень даже неплохо. Не буду нагнетать интригу. Она вообще не человек. Она - нейронка. Будет жить в нашей корпоративной сети. Можете консультироваться у неё по всем вопросам, как по профессиональным, так и по личным. Надоело мне, что вы шляетесь в рабочее время по чужим нейронкам. Поощряете развитие конкурентных программных продуктов. Да ещё и деньги свои спускаете. Наша Лиза для вас будет работать бесплатно, к тому же она заточена под потребности нашей корпорации. Значит, под ваши потребности тоже. Вопросы есть?
- А когда можно будет с ней познакомиться? - поинтересовался я.
- Хоть прямо сейчас. Доступ всем предоставлен, - объявил Борис Борисович. - И запомните главное. Не искусственный интеллект будет заменять сотрудников. А те сотрудники, которые умеют работать и ладить с искусственным интеллектом, заменят тех, кто пренебрегает современными научными открытиями.
моя недельная нагрузка (тот самый сервер с раздачей из предыдущего поста)
Покупка и управление сервером происходит в Телеграмм, на момент написания доступна Германия, Нидерланды, Белоруссия и Финляндия. Более месяца назад купил финский, проблем в установке и работе нужных мне протоколов отмечено не было. Цены Финляндия, минимальная конфигурация: 1 Core i9-9900K 3.60GHz/1 Гб ОЗУ/ 10 ГБ SSD - 150р./месяц
Через ТП возможен апгрейд, 1 CPU или 1 Гб RAM - 100р.
Сразу из минусов: нельзя автоматом изменить конфигурацию VPS, нет бэкапов, нет статистик, нет панелей... Наверное, легче сказать что тут есть - удаление сервера, перезагрузка, переустановка и продление. На этом и всё.
Понравилось тут: фактические 800-850 мбит за 150р., отличный пинг, нет рекламы на известном видеохостинге, неплохой CPU. Пополнение: крипта, российские карты
Проверка ТТХ
Скорость/трафик: заявлено 1 Гбит. Ограничения по привычному объёму в месяц нет, есть ограничение по скорости, которое зависит не от объёма, а от нагрузки. Вот что пишет тп по этому вопросу: "Если потреблять постоянно больше 300 мбит/с, то будет ограничение до 300 мбит/с на час, если продолжает нагрузка на канал, то ограничение перманентно".
Проверка качества IP
В итоге: сервер подойдёт тем кому от хостера нужен только логин и пас и кто привык всё делать сам. Если вы любитель скриптов из ЛК и красивых статистик и панелей, этот хостер точно не для вас. Для остальных - отличный сервер по минимальной цене и с неплохим железом.
P.S. наличие непостоянное, если нужна Финляндия то порой её приходится ловить, после первой покупки второй сервер отлавливал пару недель и за пару суток снова раскупили.
На удивление по алюминию работает чётко. Так же ложится и на медь и железо. Можно соединять эти металлы в любых сочетаниях (например провода) Белый налёт на месте пайки это остатки расплава флюса.
Я взял список ТОП-100 книг фэнтези и фантастики с алгоритмом и превратил в тест. Отвечаешь на вопросы и получаешь персональную рекомендацию. В подборку вошли также представители мистики, хоррора и городского фэнтези, есть как новые бестселлеры, так и классика. Был, конечно, соблазн и свои книги туда вложить, но постеснялся. (С ними можете знакомиться здесь.)
Сейчас здесь обновление только на бэке и с откатом фикса по вкладке "ответы" и откатом фикса по бану
Очень хотелось бы понять предыдущие баги связанные с тем что ленты грузились вечность и постоянно разлогинивало связаны с обновлением фронта или бэка. И Сложность в том что такое странное поведение на дев-стенде не проявляется. Там весь последний месяц все хорошо и стабильно работает.
Для этого сейчас отдельно накатан бэк и если все хорошо будет отдельно накатан фронт.
Поэтому пожалуйста, поюзайте сейчас активно капибару, походите по вкладками, пооставляйте оценок, пообновляйте страницы, покомментите, поменяйте пару символов в "обо мне" в профиле, позаходите в посты.. в общем все то что обычно делаете на капибаре, по залогинивайтесь/разлогинивайтесь, но в усиленном режиме и толпой
Если будут обнаруживаться ранее неизвестные баги или что то будет не грузиться - напишите пожалуйста в топик
Статья завершает цикл статей о тестировании методики анализа результатов нагрузочного тестирования СУБД PostgreSQL . В настоящее время ведутся работы по совершенствованию методики расчета и сбора статистических данных производительности. По окончании разработки, сценарии тестирования будут повторены , результаты опубликованы с более детальным описанием процесса и результатов.
Задача и реализация эксперимента
Установить количественное влияние расположения файловой системы WAL на производительность СУБД.
В пределе - разницы нет. Но , есть некоторые моменты.
Для тестирования используется сценарий "Insert only" : 1000 INSERT в тестовую таблицу pgbench_history.
Тестируются 2 виртуальные машины : ВМ-1 , ВМ-2.
Версия СУБД - одинакова.
ОС - одинаковая.
Гипервизор - один.
Различия:
Системный диск: HDD / SSD
Файловая система /wal: HDD / SSD
Результаты эксперимента
Пояснение : по горизонтальной оси графиков(в данной и предыдущих статьях) - количество одновременных сессий pgbench.
Производительность СУБД
Некоторая разница в производительности - все таки наблюдается
Время выполнения тестовой транзакции
Разница по времени - практически отсутствует
Относительная разница производительности и времени работы
После 20 соединений разница в производительности и времени работы - несущественна
Итоги
При данном сценарии нагрузки , в данной облачной инфраструктуре - статистически значимая разница в производительности для СУБД с расположением файловой системы WAL на диске HDD или на SSD - отсутствует.
P.S. Еще одна иллюстрация по теме влияния HDD/SSD на скорость СУБД :
If you're running it on an enterprise level server (e.g. HP Proliant or similar) then there's a good chance that that writes to the HDDs are extremely fast because they're actually being written to a non volatile write cache. Ironic because writes to SSDs are much slower than reads so SSDs typically have their own RAM based write cache.
Часть 3 - Сценарий нагрузочного тестирования "Heavyweight"
Нужно выбирать
Задача эксперимента
Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .
СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.
Сценарий "Heavyweight"
Тестовый запрос состоит только из выражений SELECT с использованием JOIN ,ORDER BY и математических функций.
Все блоки использующиеся в запросе - находятся в распределенной области.
Для создания нагрузки используется pgbench.
Количество сессий к СУБД растет экспоненциально для каждого прохода теста.
Производительность СУБД
До 78 соединений - разница в производительности не более 3%
Резкий рост относительной разницы производительности после 76 соединений
До 78 соединений - разница в производительности практически отсутствует.
При высокой нагрузке - OS-2 существенно производительнее.
Время выполнения тестового запроса
Явная аномалия в районе 78 соединений
Имеется аномалия значений
За исключением аномалии при 78 соединений, относительная разница времени выполнения не превышает 5%.
Итог
Для сценария "Heavyweight", при нагрузке свыше 78 сессий - производительность СУБД развернутой на ОС Linux версии OS-2 превосходит производительность СУБД развернутой на ОС Linux версии OS-1 более чем на 10%.
P.S. Аномальное значение при 78 сессиях нуждается в повторном эксперименте.
Прямая корреляция между количество активных сессий и производительностью СУБД . Или другими словами - чем выше нагрузка на СУБД , тем выше производительность.
Статистические показатели ожиданий СУБД - корреляция ожиданий и производительности СУБД
Рис.2. Корреляционный анализ ожиданий и производительности 13:00-13:28
Количество пользовательских запросов по которым имеются события ожидания СУБД - минимально.
Сильная обратная корреляция - чем выше нагрузка на СУБД тем ниже производительность. Явный признак инцидента производительности СУБД
Статистические показатели ожиданий СУБД - корреляция ожиданий и производительности СУБД
Рис.4. Корреляционный анализ ожиданий и производительности СУБД нисходящего тренда 13:28 - 13:47
Как видно из таблицы - количество ожиданий кардинально увеличилось. Явный признак - имеются серьезные проблемы с производительностью СУБД.
2.Определение наиболее значимой причины деградации производительности СУБД
Из Рис.4 видно, что наибольшая обратная корреляция между событиями ожидания и снижением производительности СУБД имеется для события LWLock / BufferMapping
Рис.5. Ожидание LWLock / BufferMapping
Как видно - количество ожиданий менее чем за 20 минут - весьма существенно.
Итак, первый результат
Первой( но конечно не единственной) причиной деградации производительности СУБД в период 13:28 - 13:47 является - большое количество ожиданий LWLock / BufferMapping при выполнении пользовательских запросов.
Чуть подробнее об ожидании BufferMapping
Ожидание при связывании блока данных с буфером в пуле буферов.
This event occurs when a session is waiting to associate a data block with a buffer in the shared buffer pool.
Context
The shared buffer pool is an PostgreSQL memory area that holds all pages that are or were being used by processes. When a process needs a page, it reads the page into the shared buffer pool. The shared_buffers parameter sets the shared buffer size and reserves a memory area to store the table and index pages. If you change this parameter, make sure to restart the database. For more information, see Shared Buffer Area.
The buffer_mapping wait event occurs in the following scenarios:
A process searches the buffer table for a page and acquires a shared buffer mapping lock.
A process loads a page into the buffer pool and acquires an exclusive buffer mapping lock.
A process removes a page from the pool and acquires an exclusive buffer mapping lock.
3. Определение запросов с максимальным количество ожиданий
Рис.6. Запросы с ожиданием LWLock / BufferMapping c количество более 100.
Далее, дело техники, используя утилиту pgpro_pwr по queryid, находим проблемный запрос за период 13:30 - 13:50(снимки pgpro_pwr формируются каждые 10 минут).
Запрос передается разработчикам , для анализа .
Дальнейшие события ожидания анализируются схожим образом. Если отсортировать таблицу Рис.4. по количеству пользовательских запросов(более 100) , то можно и нужно сформировать список проблемных запросов для передачи группе разработки на оптимизацию и доработку.
Рис.7. Список ожиданий отсортированный по количеству пользовательских запросов.
Итог
Статистический анализ производительности СУБД позволяет подтвердить наличие деградации производительности не дожидаясь деградации на уровне приложения.
Корреляционный анализ ожиданий и производительности СУБД позволяет быстрее определить корневую причину снижения производительности СУБД и определить список проблемных пользовательских запросов.
P.S.
В настоящее время ведутся работы по разработке и тестированию новой версии инструментария по мониторингу и анализу производительности СУБД PostgreSQL - "Орешник".
Методология статистического анализа производительности СУБД PostgreSQL будет довольно существенно дополнена и доработана.
Часть 2 - Сценарий нагрузочного тестирования "OLTP"
Выбирай сердцем
Задача эксперимента
Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .
СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.
Сценарий "OLTP"
Тестовый запрос состоит только из выражений SELECT - UPDATE.
Все блоки использующиеся в запросе - находятся в распределенной области.
Для создания нагрузки используется pgbench.
Количество сессий к СУБД растет экспоненциально для каждого прохода теста.
Производительность СУБД
Разница производительности от 5-9%
Относительная разница производительности OS-1 и OS-2
Время выполнения тестового запроса
Разница времени выполнения тестового запроса от -5% до 7%
Относительная разница времени выполнения тестового запроса
Итог
Для сценария "OLTP", при нагрузке до 111 сессий - производительность СУБД развернутой на ОС Linux версии OS-1 превосходит производительность СУБД развернутой на ОС Linux версии OS-2 на 5-9% .
Часть 1 - сценарий нагрузочного тестирования "Select only"
Какой Linux выбрать ?
Задача эксперимента
Необходимо провести количественный анализ влияния версии Linux на производительность СУБД для разных дистрибутивов Linux : OS-1 и OS-2 .
СУБД расположены на разных виртуальных машинах. Гипервизор - один. Конфигурация файловых систем - одинаковая. Ресурсы хоста - одинаковые.
Сценарий "Select only"
Тестовые запрос состоит только из выражения SELECT.
Все блоки использующиеся в запросе - находятся в распределенной области.
Для создания нагрузки используется pgbench.
Количество сессий к СУБД растет экспоненциально для каждого прохода теста.
Производительность СУБД
Разница производительности от 10 до 13%
Относительная разница производительности OS-1 и OS-2
Время выполнения тестового запроса
Разница времени выполнения тестового запроса до 7%
Относительная разница времени выполнения тестового запроса
Итог
Для сценария "Select only", при нагрузке до 111 сессий - производительность СУБД развернутой на ОС Linux версии OS-1 превосходит производительность СУБД развернутой на ОС Linux версии OS-2 не менее чем на 10% .
Статья не о сравнении ОС, задача статьи - тестирование методологии сравнения производительности СУБД.
Задача
Имеется 2 виртуальных машины с развернутой СУБД PostgreSQL.
Версия СУБД - одинаковая.
ОС - одинаковая. Гипервизор - один.
Различие - системный диск HDD vs. SSD.
Необходимо количественно определить влияние расположения файлов ОС на производительность СУБД. Т.е. определить разницу в накладных расходах для создания серверного процесса для нового соединения .
Реализация эксперимента - сценарии нагрузки
Для оценки производительности и среднего времени выполнения тестового запроса используются 3 сценария нагрузки:
Select only (условный сценарий WEB): нагрузка в виде запроса .
TPC-B (условный сценарий OLTP): Нагрузка в виде транзакции состоящей из UPDATE-SELECT
Heavyweight (условный сценарий DSS): Нагрузка в виде тяжелого запроса SELECT..JOIN..ORDER BY + вычислительная нагрузка
Индекс производительности СУБД(CPI) : операционная скорость
Время выполнения тестового запроса: скользящая медиана с периодом 1 час.
Для тестирования использовался именно этот сценарий .
Конфигурация виртуальных машин
ВМ-1
Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Soft 11.4.0-1), 64-bit
CPU = 8
RAM = 15
OC = RED 7.3
ВМ-2
Postgres Pro (enterprise certified) 14.11.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit
CPU = 24
RAM = 189
ОС = Astra Linux (Smolensk) 1.6
Итоги теста по сценарию TPC-B
Производительность ВМ-1 существенно выше ВМ-2
Т.е. по итогам данного теста получается - СУБД развёрнутая по шаблону ВМ-1 будет существенно производительнее ?
Что будет , если архитектор примет решение о выборе версии СУБД и запланирует ресурсы инфраструктуры на основании только данного теста ?
Решение проблемы
Одного теста для анализа производительности СУБД и ВМ - недостаточно.
Как было указано в документации:
Однако вы можете легко протестировать и другие сценарии, написав собственные скрипты транзакций.
Что и было сделано.
Для продолжения тестов, был подготовлен сценарий требующий серьезных вычислительных ресурсов - SELECT ... JOIN
Результат тестирования тяжелого запроса
ВМ-2 СУЩЕСТВЕННО производительнее чем ВМ-1
Все встало на свои места.
ВМ-1 даже не хватило ресурсов при количестве одновременных запросов свыше 160. При этом производительности ВМ-2 существенно выше производительности ВМ-1.
Итог
Нельзя принимать архитектурных решений на основании результатов одного только сценария нагрузочного тестирования
2. Для оценки производительности архитектурного решения по конкретной СУБД необходим комплекс разных сценариев нагрузочного тестирования.
Как минимум:
-Select only: оценка скорости чтения данных из СУБД
-Standard: оценка производительности СУБД в условиях конкуренции за блокировки.
-Heavyweight: оценка производительности СУБД при выполнении тяжелых вычислительных и ресурсоемких операций.
Туда сейчас накатан фикс баги с невидимым разлогиниванием
Хотелось бы хорошенько нагрузочно потестировать
Массово клепаем посты(можно без смысла), комментарии(смысл там тоже не важен), оценки. Ходим по вкладкам. Делаем бурную деятельность примерно как на капибаре.
Если у кого то воспроизведётся баг когда фактически разлогинило а интерфейс не показывает - вспоминаем что перед этим сделали и пишем об этом хоть мне, хоть под этим постом, хоть в багрепорты, хоть прям на деве постом
На дев-стенде верификацию просто в админке проставим всем желающим, можете бота для верификации не мучить)
Сразу к делу, за 130 рублей нам обещают тариф без ограничений 1x2.2ГГц, 0.5Гб RAM, 1IP в Казахстане.
После покупки тесты скорости показывают и правда - 100 мбит. После нагрузки системы и прокачки трафика 150 Гб. фиксируем резкий провал скорости и практический стоп.
Замеряем.
Как? Обещали же что без ограничений.
Что не так? Обещали тариф без ограничений, пишем в ТП, получаем ответ.
Важные пояснения от ТП
Хорошо, попробуем посмотреть на что можно сменить старт
Прилично так за 1/1/20
А сменить его можно только на тариф за 523 рубля и это за 1/1/20
Вот он, такой тариф без ограничений от RUVDS. Учитывая что от 110р. можно приобрести VPS с гигабитной скоростью и действительно безлимитный, покупать или нет такой тариф Старт не стоит.
