postgresql vps
Бази даних та in-memory навантаження
Достатньо пам'яті, щоб диск перестав мати значення.
Що б ми розгорнули
125,30 EUR/міс
179 EUR−30% щорічно
Після певного розміру робочого набору єдина оптимізація, що має значення — вмістити його в RAM. FORGE дає до шістнадцяти гігабайт на ядро реєстрованої ECC-пам'яті з наперед налаштованими hugepages і NUMA-обізнаним розміщенням — саме це потрібно PostgreSQL, Redis, ClickHouse та великим JVM-купам. Під ним — Gen5 NVMe у RAID10, тож записи на диск теж не стають вузьким місцем.
Чому ця конфігурація
FORGE з прив'язкою до одного NUMA-вузла тримає доступ до пам'яті локальним для сокета, що виконує роботу. Додайте нічні бекапи з тридцятьма точками відновлення, бо насправді ви зіткнетеся з поганою міграцією, а не мертвим диском.
Що б ми розгорнули
Розміри
Розмірюйте RAM під робочий набір, а не під базу. Робочий набір — це гарячі сторінки індексів плюс реально зчитувані рядки, часто 10–20% OLTP-датасету на 2 TB. Встановіть InnoDB buffer pool на 70–75% RAM, або shared_buffers Postgres на 25% і віддайте решту page cache. FORGE досягає 16 GB на ядро, тож 512 GB буферний пул сидить на ~700 GB RAM і щонайменше 44 ядрах. Якщо зчитування промахуються по кешу більш ніж 1% часу, купуйте RAM.
Hugepages, і чому THP — не те саме
Буферний пул 256 GB, відображений сторінками по 4 KB, потребує близько 64 мільйонів записів таблиці сторінок. TLB не може вмістити значущу частку цього, тому випадковий доступ платить за page walk на більшості звернень. Статичні hugepages по 2 MB скорочують кількість записів у 512 разів і з цим блукання — очікуйте помітного зниження CPU-часу на запит на великих пулах. Виділіть їх при завантаженні через vm.nr_hugepages, розмір — пул плюс ~10%, і дайте користувачеві БД ліміт memlock. Transparent hugepages досягають того ж відображення, але опортуністично, зі станами компресії. Вимкніть THP і виділяйте явно.
Робочий набір, виміряний, а не вгаданий
Не оцінюйте робочий набір за розміром директорії даних. Виміряйте. У Postgres pg_buffercache покаже, які відношення займають shared_buffers, а відношення heap_blks_hit до heap_blks_read у pg_statio_user_tables дає hit rate кешу на таблицю. У MySQL той самий сигнал — Innodb_buffer_pool_reads проти Innodb_buffer_pool_read_requests. Понад 99% — у пам'яті, і додавання RAM дає мало. Між 95% і 99% — на межі, і один неіндексований запит може зіштовхнути. Нижче 95% кожен показник латентності — насправді латентність диска в маскуванні.
Що може піти не так
- Залишений увімкненим transparent hugepages. Дефрагментація THP зупиняє процес на мілісекунди в непередбачувані моменти, що проявляється як p99-латентність, яку ніхто не може пояснити. Вимкніть і виділіть статичні hugepages.
- Ігнорування NUMA на двосокетному FORGE. Буферний пул лягає на один вузол, половина ядер читає через interconnect, і MySQL може свопати попри вільну пам'ять. Використовуйте numactl --interleave=all або явно прив'язуйте.
- Розрахунок IOPS за середньою пропускною здатністю. Checkpoint'и, vacuum і бекапи — ті піки, що мають значення. Пул, що тягне steady state, зупинить інстанс під час флашу checkpoint.
Налаштуйте машину
- Планування CPU — Single-NUMA-node affinity · 14 EUR
- Резервне копіювання — Daily backup, 30 restore points · 11 EUR
- Інше — Second-resolution metrics + alerting · 5 EUR
- Сховище та шифрування — ZFS with hourly snapshots · 7 EUR
Більше
Створено для конкретних завдань
Хостинг ігрових серверів
Тик-рейт — це задача одного потоку. Все інше — шум.
Торговий та低латентний VPS
Відстань до торгового рушія — і нічого між вами та дротом.
Приватні VPN та проксі-ендпоінти
Власний вихід у юрисдикції, яку ви обрали свідомо.
Сідбокси та масове зберігання
Терабайти, які залишаються дешевими, та порт, який залишається відкритим.
Робочі вузли Kubernetes
Дешево за ядро, щільно та однаково щоразу.
AI інференс та доналаштування
Цілий GPU, переданий повністю, на умовах, які роблять математику вигідною.