vps postgresql
Bazy danych i obciążenia in-memory
Wystarczająca pamięć, aby dysk przestał mieć znaczenie.
Co byśmy wdrożyli
125,30 €/mies.
179 €−30% rocznie
Powyżej pewnego rozmiaru working set jedyną optymalizacją, która się liczy, jest zmieszczenie całości w RAM. FORGE daje do szesnastu gigabajtów na rdzeń zarejestrowanej pamięci ECC z prekonfigurowanymi hugepages i umiejscowieniem NUMA, czego chcą PostgreSQL, Redis, ClickHouse i duże sterty JVM. Pod spodem jest Gen5 NVMe w RAID10, więc zapisy, które trafiają na dysk, też nie są wąskim gardłem.
Dlaczego ta konfiguracja
FORGE z afinitetem do jednego NUMA utrzymuje dostęp do pamięci lokalnym dla gniazda wykonującego pracę. Dodaj nocne backupy z trzydziestoma punktami przywracania, bo awaria, którą faktycznie napotkasz, to zła migracja, nie martwy dysk.
Co byśmy wdrożyli
Rozmiar
Rozmiar RAM do working set, nie do bazy. Working set to gorące strony indeksów plus wiersze faktycznie dotykane, często 10-20% zbioru OLTP o wielkości 2 TB. Ustaw InnoDB buffer pool na 70-75% RAM, a shared_buffers Postgresa na 25%, resztę zostawiając page cache. FORGE osiąga 16 GB na rdzeń, więc pula buforowa 512 GB siedzi na około 700 GB RAM i co najmniej 44 rdzeniach. Jeśli odczyty pudłują w cache częściej niż w 1% przypadków, kup RAM.
Hugepages i dlaczego THP to nie to samo
Pula buforowa 256 GB mapowana w stronach 4 KB potrzebuje około 64 milionów wpisów tablicy stron. TLB nie utrzyma znaczącej ich części, więc losowy dostęp płaci page walk przy większości odwołań. Statyczne hugepages 2 MB zmniejszają liczbę wpisów 512 razy, a z nimi walki — spodziewaj się mierzalnego spadku czasu CPU na zapytanie przy dużych pulach. Przydziel je przy bootowaniu przez vm.nr_hugepages, rozmiar dla puli plus około 10%, i daj użytkownikowi bazy limit memlock. Transparent hugepages osiągają to samo odwzorowanie, ale robią to oportunistycznie, ze stallami kompakcji. Wyłącz THP i przydzielaj jawnie.
Working set, mierzony, nie zgadywany
Nie szacuj working set z rozmiaru katalogu danych. Zmierz go. W Postgresie pg_buffercache mówi, które relacje zajmują shared_buffers, a stosunek heap_blks_hit do heap_blks_read w pg_statio_user_tables daje wskaźnik trafień cache na tabelę. W MySQL Innodb_buffer_pool_reads przeciw Innodb_buffer_pool_read_requests daje ten sam sygnał. Powyżej 99% jesteś w pamięci i dodanie RAM-u kupuje niewiele. Między 95% a 99% jesteś na krawędzi, a jedno niezaindeksowane zapytanie może cię przez nią przepchnąć. Poniżej 95% każda liczba latencji, którą masz, to naprawdę liczba latencji dysku w przebraniu.
Co może pójść źle
- Zostawienie włączonych transparent hugepages. Defragmentacja THP wstrzymuje proces na milisekundy w nieprzewidywalnych momentach, co objawia się p99 latencji, której nikt nie umie wytłumaczyć. Ustaw na never i przydziel statyczne hugepages.
- Ignorowanie NUMA na dwugniazdowym FORGE. Pula buforowa ląduje na jednym węźle, połowa rdzeni czyta przez interconnect, a MySQL może swapować mimo wolnej pamięci. Użyj numactl --interleave=all lub zwiąż jawnie.
- Wyliczanie IOPS ze średniego throughputu. Checkpointy, vacuum i backupy to szczyty, które się liczą. Pula radząca sobie ze stanem ustalonym zatrzyma całą instancję podczas fluszu checkpointu.
Dostrojenie maszyny
- Planowanie CPU — Single-NUMA-node affinity · 14 €
- Kopie zapasowe — Daily backup, 30 restore points · 11 €
- Wszystko inne — Second-resolution metrics + alerting · 5 €
- Pamięć i szyfrowanie — ZFS with hourly snapshots · 7 €
Więcej
Stworzone dla konkretnych zadań
Hosting serwerów gier
Tick rate to problem jednowątkowy. Reszta to szum.
VPS do tradingu i niskich opóźnień
Odległość do silnika dopasowującego zlecenia i nic między Tobą a siecią.
Prywatne punkty końcowe VPN i proxy
Twój własny punkt wyjścia, w jurysdykcji wybranej celowo.
Seedboxy i magazyn masowy
Terabajty, które pozostają tanie, i port, który pozostaje otwarty.
Węzły robocze Kubernetes
Tanio za rdzeń, gęsto i identycznie za każdym razem.
Inferencja AI i fine-tuning
Całe GPU, przepuszczone, na zobowiązaniu, które czyni matematykę sensowną.