Владел Грантой с 2015 по 2021 год, третий владелец. Решил продать. Как и ТС, сначала пробил по базам, и... опа! запрет на действия!
Пошёл к соседке, она работает в ФССП, прямо со своего телефона пробила по их базам. И да, арест наложен в 2017 году на первого (!) владельца, который владел машинкой три месяца в 2012 году. То есть, авто сменило уже двух владельцев, и вот - нате вам.
Поехал в соседний город, где проживает первый владелец, в территориальный отдел ФССП. Всеми правдами и неправдами в конце рабочего дня просочился к приставу, который наложил арест. Показал ему все доки, ДКП, СТС, ПТС. Написал по его просьбе заявление, что не верблюд авто давно числится за мной. При мне он посмотрел в комп, и выдал обещание, что уберёт запись из базы, как неточную. Ага, свежо предание... Так вам и поверил. Включил режим наглости и сказал, что с места не сдвинусь, пока он не удалит эту запись. Он вздохнул, и сделал требуемое в течение одной минуты.
Вуаля...
Потом уже, как-то в разговоре со знакомым сотрудником ГИБДД упомянул эту историю, а тот пояснил, что базы ФССП и ГИБДД не всегда совпадают. Хотя обновления синхронизации баз происходит каждые три месяца.
p99 fsync против пиковых IOPS сравнивать бессмысленно, поскольку показатели снимают в разных режимах работы накопителя. Для WAL важна хвостовая задержка fsync при подтверждённой записи, тогда как пиковые IOPS обычно получают с глубокой очередью. Вывод действует только для указанной конфигурации: устройства, файловой системы, кэша, sync-метода и нагрузки.
Почему p99 fsync полезнее пиковых IOPS?
p99 fsync показывает границу, ниже которой уложились 99% синхронизаций в прогоне. Пиковые IOPS показывают пропускную способность при заданной очереди и ничего не говорят об одном flush WAL. Но и p99 оценивают только вместе с числом операций, длительностью теста и конфигурацией конкретного хранилища.
Показать, где WAL ждёт подтверждения записи
При COMMIT процесс добавляет запись о завершении транзакции в WAL и вызывает XLogFlush до нужного LSN. PostgreSQL сбрасывает WAL-буферы в файл, затем просит ОС синхронизировать его. При synchronous_commit=on клиент получает подтверждение после локального flush. Если настроена синхронная репликация, время ответа также зависит от ожидания standby и выбранного режима.
Способ синхронизации WAL задаёт wal_sync_method. На Linux по умолчанию используется fdatasync: PostgreSQL пишет WAL через файловый кэш, затем вызывает fdatasync(). Варианты open_datasync и open_sync открывают файл с другими флагами. Семантика каждого варианта разобрана в документации PostgreSQL, а скорость проверяют на файловой системе будущего pg_wal.
Завершённый write() ещё не говорит о сохранности после потери питания, поскольку данные могли остаться в памяти ядра или энергозависимом кэше контроллера. Поэтому хвостовая задержка fsync включает работу ядра, файловой системы и контроллера, а не только запись блока. Перед тестом фиксируют устройство, LVM или RAID, mount options, политику кэша и наличие power-loss protection.
Почему пик операций не предсказывает транзакционную задержку
IOPS измеряют числом завершённых операций за секунду. Высокий результат часто получают с десятками запросов в очереди, чтобы контроллер использовал параллелизм NAND. При одиночном COMMIT это преимущество исчезает, так как транзакция ждёт конкретный flush.
Средняя latency тоже скрывает паузы. Если 9900 синхронизаций заняли 0,2 мс, а 100 заняли 20 мс, среднее составит около 0,4 мс, хотя у 1% транзакций задержка будет около 20 мс. Заявленная p99 задержка хранилища требует единиц, числа выборок и периода. Без них доля медленных операций неизвестна.
Глубину очереди меняют отдельной серией. QD=1 показывает задержку без очереди, а QD=8 или 32 проверяет параллелизм. При синхронном psync значение iodepth выше единицы не создаёт настоящую очередь, поэтому нужен асинхронный engine с direct=1. Полученную пропускную способность нельзя выдавать за задержку WAL и тем более сравнивать с рекламным read IOPS.
Читать p50, p95 и p99 как форму риска
Перцентили относятся к одному распределению. p50 делит выборку пополам, выше p95 остаются 5% операций, выше p99 остаётся 1%. Для 100 000 операций этот хвост даёт около тысячи наблюдений, а для 1000 – только десять, поэтому маленькая выборка сильнее реагирует на шум.
Как измерять fsync при реалистичной нагрузке?
Воспроизведите условия реального WAL: размер синхронной записи, конкурентность, глубину очереди, sync-метод и файловую систему. Измеряйте после прогрева устройства. Затем сохраните полное распределение, число операций и временной ряд вместе с политикой кэша. После микротеста проверьте вывод транзакционной нагрузкой при тех же гарантиях сохранности данных.
Показатели p50/p95/p99 дополняют гистограммой: по ней видно, образует ли хвост один пик или несколько режимов. На графике, где IOPS отложены против задержки, подпишите block size, queue depth, jobs и длительность. Максимум сохраняют отдельно, так как выброс мог совпасть с checkpoint, discard или работой гипервизора.
По временному ряду видно, распределены ли редкие паузы по всему тесту или хвост создал один провал. Всплески сопоставляют с выводом iostat -x 1, телеметрией NVMe и checkpoint.
Повторить размер записи, очередь и конкурентность WAL
Как правило, сначала фиксируют версию PostgreSQL, wal_sync_method, synchronous_commit, объём WAL за секунду и число одновременно завершающихся транзакций. Скорость генерации WAL считают по разнице показаний pg_stat_wal, а конкурентность берут из журналов и метрик за тот же период. Размер синхронной записи берут из реального профиля, а при его отсутствии помечают как допущение. При конкуренции PostgreSQL может подтвердить несколько транзакций одним flush, поэтому число синхронизаций окажется меньше числа COMMIT.
Сначала моделируют одиночную синхронизацию с выбранным размером блока, например 8 KiB: один job, QD=1, тот же каталог и sync-метод. Затем повышают число jobs. Асинхронный QD-тест идёт отдельно, иначе невозможно понять, что дало прирост: конкурентность приложения или внутренняя очередь устройства.
Набор данных и длительность выбирают так, чтобы тест не закончился на быстром кэше. Для виртуального диска указывают thin provisioning, репликацию и локальный кэш. Бенчмарк надёжной записи, упирающийся в RAM или короткий SLC-burst, ничего не показывает. Поэтому в отчёт вносят свободное место, заполнение и способ предварительной записи.
Согласовать pg_test_fsync, fio и транзакционный прогон
pg_test_fsync сравнивает способы синхронизации и выводит среднее время операции. По документации PostgreSQL файл размещают на той же файловой системе, где будет pg_wal. Утилита помогает выбрать wal_sync_method, но не показывает хвост распределения и не предсказывает пропускную способность базы.
В прогоне, опубликованном 27 мая 2025 года, использовались PostgreSQL 16, Samsung 990 Pro, XFS и write-back-кэш. Фрагмент сырого вывода:
На том же сервере, но на Micron 7400 с PLP среднее время fdatasync составило 24 мкс. Полный вывод и топология стенда есть в исходном отчёте, но из-за разной конфигурации это сравнение классов накопителей, а не моделей.
Чтобы получить распределение, используют fio job, в котором заданы engine, block size, QD и длительность. Укажите отдельный тестовый файл: fio перезапишет его и потребует не менее 32 GiB свободного места.
Команда fio wal-fsync.fio --output=wal-fsync.txt --output-format=normal сохраняет отчёт, а percentile_list задаёт перцентили. Для WAL смотрите раздел fsync/fdatasync/sync_file_range. Отдельная асинхронная серия покажет, как меняется задержка NVMe при разной глубине очереди. Затем подтвердите результат в pgbench с -l или прикладном сценарии при тех же гарантиях сохранности данных.
Поймать cache exhaustion, flush и фоновые паузы
Короткий запуск может закончиться до исчерпания быстрого кэша SSD. Поэтому файл предварительно заполняют, устройство прогревают, а тест ведут до устойчивого режима. По временному ряду видно, как после исчерпания SLC-кэша падает пропускная способность или растёт задержка. Там же видны фоновые паузы. Один итоговый p99 смешивает быстрый старт с установившимся режимом.
Перед серией фиксируют write cache, PLP, температуру, прошивку, заполнение, discard и фоновые операции. Что из этого списка недоступно на виртуальном диске, также отмечают в отчёте. Кэш не отключают, поскольку тест повторяет рабочую конфигурацию, а потерю питания проверяют отдельно.
Какой p99 допустим для транзакционной нагрузки?
1. Универсального порога нет: вычтите из SLO время сети, блокировок, CPU и других синхронных шагов.
2. Определите, какую часть остатка можно отдать ожиданию WAL с учётом group commit.
3. Задайте запас и долю нарушений, затем подтвердите порог транзакционным тестом.
p99 fsync 5 мс уже больше, чем весь SLO в 4 мс. При SLO 100 мс такая задержка может поместиться в бюджет только после учёта остальных ожиданий. Результат проверяют после прогрева и при рабочем заполнении диска, а критерий пересматривают при смене прошивки, миграции VM или росте нагрузки.
Связать хвост fsync с SLO транзакций
p99 fsync нельзя напрямую приравнивать к p99 транзакции. В критический путь транзакции входят блокировки, вычисления, сеть, репликация и иногда несколько flush. Group commit объединяет синхронизации, а synchronous_commit=off убирает ожидание локального диска. Поэтому перед сравнением выясняют, какие этапы идут последовательно, а какие перекрываются.
Затем сопоставляются временные ряды. Если пики commit latency совпадают с ростом времени WAL fsync, await и длины очереди, накопитель становится основной гипотезой. Если метрики хранения остаются ровными, задержку ищут в блокировках, CPU или ожидании реплики. Причину подтверждают изменением одного фактора: устройства, sync-метода или профиля нагрузки.
В SLO записывайте порог, долю нарушений, окно и минимальное число операций. Вместе с результатами транзакционного теста нужно сохранить latency histogram, указав границы бакетов и число наблюдений. Размер запаса задаётся до серии. При росте конкурентности тест лучше повторить: очередь и group commit меняют связь между одним flush и числом завершённых транзакций.
Сделать результат проверяемым на другом стенде
К job-файлу и сырому выводу обычно добавляют дату, версии fio, PostgreSQL и ядра, файловую систему и mount options, модель и прошивку диска, RAID/LVM, кэш и PLP, размер файла, block size, QD, jobs, длительность и прогрев. Для VM также указывают контроллер и неизвестные свойства хранилища.
В папку результата положите fio.job, fio.txt, вывод pg_test_fsync, журналы pgbench, iostat, NVMe log и CSV временного ряда. Рядом с графиком приведите перцентили и число операций. Без исходных файлов нельзя проверить единицы, фильтрацию и границы интервала.
У steady-state workload должен быть критерий: например, 10 минут после 5-минутного прогрева или остановка fio по условию steady state. Выбор зафиксируйте в job-файле. В краткой версии публикации оставьте график p99 и ссылку на полную методику.
Хранилище для WAL выбирают по повторяемой задержке подтверждённой записи и по тому, укладывается ли транзакция в свой SLO. Сначала проверьте sync-метод на файловой системе pg_wal, затем снимите распределение задержек в fio и подтвердите вывод транзакционным тестом. Сырой вывод нужен, чтобы не спутать смену накопителя с изменением нагрузки. После такой проверки p99 fsync против пиковых IOPS перестаёт быть выбором между двумя цифрами: для планирования берут p99, измеренный при нужных гарантиях записи и сопоставленный с SLO.
еклама. ООО «Аеза Групп», ИНН: 7813654490. erid: 2RanykUKFPq
1. Есть ли у кого-то БД/сливы аккаунтов или перечни игроков LiteCloud 2016-17 и LastCraft 2020-21 годов? Пытаюсь найти все свои ники, особенно те, что были до вайпа/обновления режима Creative (на котором в основном и играл) в 2017 (если не ошибаюсь). Были ли таблицы/утечки где-то после или во время июня 2016? Я точно помню, что тогда были сливы. Тогда украли и мой аккаунт в том числе. К слову, на LiteCloud же публиковали логи банов? По ним тоже можно искать информацию... Я точно помню, что и сам кидал видео с читерами. Или это был LastCraft?
Хотя их облазить у меня ногтей не хватит... может, там тоже есть скриншоты плотов на креативе.
3. Никто не знает, можно ли узнать администраторов/модераторов группы Скрины В Майнкрафт? Спрашивал людей, оставивших комментарии — это пока не дало результата. https://vk.ru/screenshots_in_minecraft
По мере нахождения информации постараюсь дополнять всё. Вдруг найдутся такие же головы, обращённые назад. В общем, приветствуется всё — скриншоты, видео, таблицы, БД, группы.
Всем привет, меня зовут Сергей Па́токин, и здесь я расскажу историю про свои 18 карат невезения и участие в научной конференции.
В декабре 2020 года произошло событие, которого более пятидесяти лет ждали криптографы, журналисты и люди, добровольно изучающие переписку серийного убийцы.
Был расшифрован Z340 – один из четырёх известных шифров Зодиака, орудовавшего в конце шестидесятых годов.
С задачей справились три программиста-энтузиаста из разных стран:
Дэвид Оранчак из США;
Сэм Блейк из Австралии;
Ярл Ван Эйке из Бельгии.
Они не представляли одну государственную лабораторию и не располагали секретным суперкомпьютером. Просто три человека объединили знания, разработали необходимые инструменты и решили задачу, которая десятилетиями считалась практически неприступной.
Оригинальный шифр Z340
Z340. Триста сорок символов, несколько десятилетий попыток и три программиста, которым никто не объяснил, что подобные проекты лучше оставить на старшие курсы.
В расшифрованном тексте находилось обращение к полиции и рассуждения самого убийцы. Зодиак писал о том, что не боится казни, и продолжал поддерживать образ человека, которому известно нечто недоступное остальным.
До этого был расшифрован только Z408 – первое большое криптографическое послание Зодиака. Его разгадали ещё в 1969 году. В нём автор сообщал, что любит убивать людей, потому что это весело.
Мысль достаточно простая. Для её передачи потребовалось более четырёхсот символов и полвека внимания к личности автора.
Оставшиеся шифры продолжали сопротивляться анализу.
И вот спустя более пятидесяти лет нашлись люди, которые смогли расшифровать один из них.
О расшифровке Z340 я узнал почти сразу.
К тому моменту я уже хорошо знал биографию Зодиака, историю его преступлений, писем и публичной игры с полицией и газетами. Разумеется, я знал и о его шифрах.
Новость меня невероятно вдохновила.
Я подумал:
Смогли они – смогу и я.
На тот момент я только поступил в университет и учился на первом курсе направления «Информатика и вычислительная техника» в филиале МГТУ имени Баумана.
Я был начинающим программистом, но уже достаточно уверенно владел языками программирования и представлял алгоритмы, которые можно было реализовать для анализа другого шифра Зодиака – Z13.
Возможно, самого важного из оставшихся.
Шифр Z13
Z13 – предположительно, имя Зодиака. Всего тринадцать символов.
В сопровождавшем шифр письме Зодиак утверждал, что внутри содержится его настоящее имя.
В другой истории для решения проблемы было бы достаточно узнать имя человека и увидеть его лицо. В моей сначала требовалось расшифровать тринадцать символов, а затем каким-то образом доказать, что полученное имя действительно настоящее.
Проблема заключалась именно в длине шифра.
Для сравнения: в Z340 было триста сорок символов.
Если после расшифровки длинного сообщения получается связный текст с предложениями и устойчивым смыслом, можно с достаточно высокой уверенностью предположить, что решение найдено.
Если результатом тринадцати символов должно стать имя, вариантов становится почти бесконечно много.
Имя может быть настоящим или вымышленным, полным или сокращённым. Оно может содержать ошибку, псевдоним или дополнительный знак. Кроме того, Зодиак мог солгать.
Это предположение не требовало особенно смелой научной гипотезы.
Поэтому главная сложность состояла не в том, чтобы получить варианты расшифровки. Главная сложность – понять, что среди них есть правильный.
Я осознавал это с самого начала.
Но решил двигаться от малого: реализовать несколько возможных алгоритмов, выделить подходящие варианты и постепенно сокращать пространство поиска.
Научный проект
Весной 2021 года в университете проходила ежегодная научная конференция.
Я решил, что дешифратор Z13 станет отличной темой для проекта, пришёл на кафедру и записался.
Тема быстро стала известна среди моих однокурсников. Люди подходили, задавали вопросы, интересовались историей Зодиака и тем, каким образом я собираюсь анализировать шифр.
Я с энтузиазмом рассказывал о задумке, алгоритмах и перспективах проекта.
Постепенно о работе начали говорить преподаватели и другие сотрудники университета. На фоне стандартных студенческих разработок попытка расшифровать имя одного из самых известных неустановленных серийных убийц действительно привлекала внимание.
Первая программа
Для проекта я разработал две программы.
Первая выполняла полный перебор возможных вариантов расшифровки латинского текста.
Теоретически она гарантированно должна была обнаружить правильную последовательность – при условии, что эта последовательность вообще находилась внутри выбранного пространства поиска.
Проблема была лишь в количестве вариантов.
Полностью выполнить такой перебор на доступном мне оборудовании было невозможно из-за ограничений вычислительной мощности и памяти. Даже если бы программа завершила работу, она выдала бы огромное количество результатов, среди которых всё равно требовалось определить единственно правильный.
Но сам факт того, что нужная комбинация гарантированно присутствует среди результатов, представлялся мне интересным. Поэтому программу я реализовал как демонстрацию метода.
Технически это была конструкция с многократной вложенностью циклов.
Моя первая и, вероятно, единственная программа, в которой каждый новый уровень вложенности выглядел как ещё одна дверь, за которой находилась следующая дверь.
Код первой программы
Полный перебор. Для завершения требовались несколько тысяч лет или примерно 1,21 гигаватта.
База имён и фамилий
Вторая программа была более практичной.
Она работала с базами реальных имён и фамилий.
Готовой подходящей базы у меня не было, поэтому я начал формировать её самостоятельно. В первую очередь собирал распространённые имена и фамилии жителей США, поскольку именно там действовал Зодиак. Затем начал расширять выборку, добавляя варианты из других стран.
Имена и фамилии хранились отдельно.
Это позволяло проверять разные комбинации:
имя;
фамилию;
имя и фамилию вместе;
сокращённые варианты;
перестановки;
преобразования каждой части по отдельности.
В результате я собрал несколько тысяч имён и фамилий вручную, потому что бюджет проекта состоял из энтузиазма, свободного времени и крышек, которые университет почему-то не принимал.
Значительную часть информации приходилось искать, проверять, приводить к единому формату и вручную добавлять в локальную базу.
Я не просто написал алгоритм. Я своими силами формировал данные, на которых он должен был работать.
Фрагмент локальной базы имён и фамилий
Часть локальной базы. Несколько тысяч имён и фамилий, собранных вручную.
Первым делом я проверял сравнительно простые варианты:
прямую подстановку;
шифр Цезаря с различными смещениями;
перестановки символов;
несколько вариантов преобразования алфавита;
комбинации имён и фамилий;
сопоставление структуры повторяющихся знаков.
Постепенно я объединил несколько алгоритмов в одной программе. Она брала записи из базы, преобразовывала их разными способами и сравнивала получившиеся последовательности со структурой Z13.
Совпадений я не получил.
Ни одного.
Ни по одному из реализованных алгоритмов.
Это не было расшифровкой, но тоже представляло собой результат.
Несколько тысяч распространённых имён, несколько тысяч фамилий, различные комбинации и базовые алгоритмы не дали даже убедительного кандидата.
Это могло означать, что либо Зодиак использовал более сложный принцип шифрования, либо записал имя нестандартным способом, либо внутри вообще находилось не имя.
Был и ещё один вариант: Зодиак мог намеренно создать строку, не имеющую однозначного решения, а затем объявить, что спрятал в ней свою личность.
Для человека, который годами кормил прессу загадками, это выглядело вполне последовательно.
В дальнейшем я планировал приобрести более крупную официальную базу имён и фамилий. Она позволила бы расширить поиск и перейти от самостоятельно собранной выборки к более серьёзному массиву данных.
Для этого требовалась поддержка университета.
Выступление на конференции
Весной на научной конференции я подробно представил свою работу.
Рассказал об истории шифров Зодиака, принципах шифрования, расшифровке Z340 и особенностях Z13.
Объяснил, почему малое количество символов не упрощает задачу, а делает проверку результата почти невозможной.
Показал обе программы:
полный перебор;
систему анализа реальных имён и фамилий.
Продемонстрировал принцип их работы, рассказал о собранной базе данных, перечислил проверенные алгоритмы и обозначил дальнейшие направления исследования.
У меня не было готовой расшифровки.
У меня была сложная нерешённая задача, собственные программные инструменты, несколько тысяч собранных записей, результаты проверки гипотез и план развития проекта.
То есть исследовательская работа.
Слушателей проект заинтересовал. На фоне остальных выступлений тема выглядела необычно.
Мой научный руководитель – заведующий кафедрой и одновременно один из членов жюри – посмотрел на меня с некоторым сожалением.
Результаты конференции ещё не объявили, но мне уже начали объяснять, что я учусь только на первом курсе, что впереди будет много других проектов и что расстраиваться не следует.
Обычно человека утешают после объявления результатов.
Меня это несколько озадачило.
Научная объективность
Первые три места заняли проекты, связанные с разработкой типовых телеметрических приборов.
Темы этих проектов студентам рекомендовали преподаватели кафедры. Сами приборы были нужны кафедре.
Пока я самостоятельно искал способ решить нерешённую задачу, другим участникам уже выдали задание, указали направление и поставили маркер над конечной точкой. Оставалось только не свернуть по дороге исследовать ближайшую пещеру.
Проекты кафедры решали задачи кафедры, получали поддержку кафедры и затем оценивались представителями кафедры.
Наука иногда удивляет совпадениями.
Победившие работы опубликовали в университетском журнале. Кафедра получила необходимые ей разработки, студенты получили места, а система – ожидаемый результат.
Но не расшифровал же
Во время объявления результатов заведующий кафедрой снова отдельно упомянул мой проект.
И произнёс фразу, которую я запомнил навсегда:
Да, ты пытаешься расшифровать шифр. Но не расшифровал же.
Тогда я подумал:
Вот так да. Если бы я уже расшифровал имя Зодиака, вероятно, представлял бы результат в Гарварде.
Чтобы работа первого курса считалась достаточно успешной, мне следовало окончательно решить одну из самых известных криптографических загадок XX века.
Желательно за несколько месяцев, на домашнем компьютере и с базой данных, собранной вручную.
После этого можно было бы конкурировать с прибором, техническое задание для которого заранее подготовила кафедра.
Возможно.
Заведующий кафедрой снова сказал, что проект хороший, но я нахожусь только на первом курсе и у меня всё впереди.
Остальные участники, насколько я помню, тоже не успели состариться в стенах университета.
Просто у их проектов был более прямой маршрут к результату.
Так закончилась моя история про 18 карат невезения.
Что было дальше
Свою идею я не бросил.
Я лишь отложил её и позднее периодически возвращался к проекту по мере развития искусственного интеллекта и появления новых методов обработки данных.
Технологии постепенно давали возможности, которых у меня не было весной 2021 года.
Можно было расширять базы, использовать статистические модели, анализировать вероятности, искать закономерности и проверять значительно больше гипотез.
Но первая конференция дала мне отдельный результат, не связанный с криптографией.
Я понял, что научная среда не всегда продвигает неизвестное. Неизвестность неудобна: она не гарантирует готового устройства, публикации и результата к установленной дате.
Настоящая исследовательская задача может закончиться отрицательным результатом. Может потребовать годы. Может вообще не иметь однозначного решения.
Именно поэтому она является исследовательской задачей.
Но для победы на конференции значительно надёжнее разработать то, что уже ждут в соседнем кабинете.
С Зодиаком всё было проще.
Он хотя бы не притворялся, что играет честно.
---
К Z13 я ещё вернусь – уже с современными моделями, более крупными базами и методами, которых у меня не было в 2021 году.
Если вам интересны исследования в области программирования, искусственного интеллекта, или же просто безумные истории разработчика, который в силовой броне стремится в форбс (тяжело, шумно, но уверенно тащу ядер-колу на продажу), подписывайтесь. Здесь будут и другие мои проекты. В том числе расскажу про свою разработку видеоигр.
Какие методы вы бы проверили на тринадцати символах в первую очередь?
Возникло из обсуждения с коллегой, когда оказалось, что и её, и меня разные тестеры-индусы пытались напрячь на обновление тестовых данных в базе по причине "у меня не хватает прав для обновления". И внезапно после созвона и просьбы продемонстрировать простой UPDATE оказывается, что все права есть. Просто они боятся что-то делать с базой и предпочитают свалить эту задачу на разработчиков, чтоб разработчики бегали и настраивали им тестовые данные.
"Когда тупое думает, что оно хитрое". Простите за грубость, но точнее не сказать.
А как искренне они удивляют, что все права, оказывается, есть!
Для СУБД важна не максимальная скорость в коротком тесте, а стабильный отклик диска под рабочей нагрузкой. Требования к I/O зависят от профиля: OLTP, аналитика и смешанные нагрузки по-разному используют чтение, запись, WAL, временные файлы и кэш. VDS для баз данных оценивают по стабильному IOPS, p99-задержке и поведению под длительной нагрузкой, а не по лучшей цифре из прайса.
Почему БД чувствительны к стабильности I/O
PostgreSQL пишет WAL, MySQL – redo log и, если включён, binlog. При скачках задержки fsync с 2 до 80 мс транзакции могут ждать диск, а очередь запросов расти даже при нормальной средней скорости. io_wait сам по себе не всегда означает проблему: его нужно смотреть вместе с latency диска, p95/p99 и временем ответа запросов.
Пиковая скорость vs устойчивый IOPS
На VDS с burst-профилем короткий тест может показать высокий результат, но через несколько минут упереться в лимит хоста или нагрузку соседних VM. Для OLTP важнее, чтобы 5 000 IOPS держались ровно 10–15 минут, чем разовый пик в 50 000 IOPS на старте теста.
Метрики, на которые смотреть
Смотрите не только среднюю задержку, а p95/p99, джиттер и самые медленные операции записи. Оценивать график лучше относительно SLO конкретной СУБД и приложения: p99-задержка, время ответа запросов и io_wait не должны регулярно выходить за допустимые для проекта значения при одинаковой нагрузке.
Как проверить VDS перед миграцией БД
Перед переносом запустите fio со случайным чтением и записью блоками 4K минимум на 10 минут и отдельно проверьте СУБД через pgbench или другой нагрузочный тест. fio помогает оценить диск, но не полностью повторяет поведение PostgreSQL или MySQL: важны WAL, fsync, cache hit ratio и размер рабочего набора данных. Размер тестового файла должен быть больше объёма памяти, который может использоваться под page cache, иначе результат может попасть в кэш и показать нереалистично высокую скорость. Тестируйте VDS-сервер в то же время суток, когда у проекта обычно пиковая нагрузка.
Что замерить до переноса продакшена
• Стабильный IOPS на длительном fio-тесте
• p99-задержка чтения и записи
• p99-задержка fsync при типичной нагрузке вашей СУБД
• io_wait во время pgbench или тестовой нагрузки
• Наличие резервирования дисков, RAID-схему и поведение платформы при сбое накопителя
• Доступный объём RAM, использование page cache и активность swap под нагрузкой
• Поведение диска после 10–15 минут непрерывной нагрузки
До миграции продакшена проверьте диск под реальный профиль БД, а после переноса повторите тесты уже на рабочей нагрузке. Если тест показывает стабильную p99-задержку без резких всплесков, миграция будет менее рискованной: вы выбираете сервер по поведению под нагрузкой, а не по пиковой скорости.
У провайдеров VPS и VDS часто выглядят как синонимы. Поэтому сравнивать нужно не название услуги, а тип виртуализации, лимиты ресурсов и гарантии для продакшен-нагрузок.
В чём реальная разница между VPS и VDS?
VPS и VDS у разных провайдеров часто используются как синонимы, поэтому название услуги само по себе ничего не гарантирует. Практическая разница появляется не в названии, а в типе виртуализации: контейнерная схема (OpenVZ, Virtuozzo, LXC) делит ядро хостовой ОС, а аппаратная виртуализация (KVM, Xen) даёт отдельное ядро гостевой системы и более чёткие границы ресурсов.
Почему изоляция ресурсов критична
На контейнерной схеме CPU и I/O могут делиться между всеми на хосте, а степень изоляции зависит от настроек хоста, лимитов и политики провайдера. Современные контейнерные решения могут нормально работать под нагрузкой, если ресурсы распределены корректно. Если сосед по железу активно загружает физические ядра или диск, ваш контейнер может тормозить, а без доступа к хостовой стороне причину сложнее подтвердить.
Например, два тарифа могут иметь одинаковые характеристики: 4 vCPU и 8 ГБ RAM. Один сервер будет работать стабильно под нагрузкой благодаря корректным лимитам ресурсов и контролю плотности размещения VM, а другой может показывать просадки из-за высокой конкуренции за ресурсы на хосте.
CPU steal time (%st в top и vmstat) показывает, сколько времени виртуальный процессор ждал, пока гипервизор выделит ему физическое ядро. Проще говоря, это время, когда VPS хотел получить CPU, но физический ресурс был занят другими задачами на хосте. При нормальной конфигурации хоста показатель держится близко к нулю. fio и vmstat позволяют увидеть симптомы деградации (рост latency, steal time), но не позволяют однозначно подтвердить оверселлинг.
Сценарии, где разница решает
• PostgreSQL и MySQL под нагрузкой: нужна I/O-предсказуемость и стабильный RAM.
• Low-latency API: скачки задержки в правильно написанном сервисе могут быть связаны с CPU steal, I/O или нагрузкой на сеть, а не только с кодом.
• CI/CD-раннеры и k8s-ноды: всплески нагрузки у соседей не должны валить ваши сборки и поды.
Чек-лист: как проверить изоляцию у провайдера
• Тип виртуализации: KVM/Xen или OpenVZ/LXC?
• vCPU гарантированы или мягкий лимит с троттлингом?
• Есть ли гарантии IOPS или диск работает в shared-режиме без ограничений?
• Публикует ли провайдер политику оверселлинга?
• Можно ли измерить steal time через vmstat или встроенный мониторинг?
Перед выбором тарифа пройдитесь по этому чек-листу. Маркировка «VDS» на сайте провайдера не гарантирует аппаратной изоляции, посмотрите тип гипервизора отдельно.
