Bağlantı Havuzu — Büyük Havuz Hızlı Havuz Değildir

Siparişler zaman aşımına uğramaya başlayınca ekip havuzdaki bağlantı sayısını 10’dan 100’e çıkardı. Bir hafta sonra asıl sebep bulundu: ödeme çağrısı transaction’ın içindeydi.

Havuz neden var?

Yeni bir veritabanı bağlantısı açmak ucuz değildir: ağ bağlantısı, TLS, kimlik doğrulama ve PostgreSQL’de sunucu tarafında yeni bir süreç. Bu yüzden uygulama açık bağlantıları bir connection pool?Terimin tanımını açconnection poolAçık veritabanı bağlantılarını tutan ve isteklere ödünç veren havuz. Bağlantı açmanın maliyetini bir kez öder; boyutu veritabanının kapasitesine göre seçilir.Sözlükte gör →’da tutar ve istekler onları ödünç alıp iade eder.

Spring Boot’ta varsayılan havuz HikariCP’dir. Varsayılan maximumPoolSize 10, bağlantı bekleme süresi (connectionTimeout) 30 saniyedir.

Kaç bağlantı?

PostgreSQL wiki’si ve HikariCP belgeleri başlangıç noktası olarak şu formülü verir: bağlantı = (çekirdek × 2) + etkin disk sayısı. Bu bir başlangıçtır; son boyutu yük testinde bekleme ve gecikmeye bakarak ayarla.

Birden çok pod varsa toplam önemlidir: pod sayısı × havuz boyutu, veritabanının bağlantı sınırını (PostgreSQL’de varsayılan max_connections 100) aşmamalı.

Kendin gör

1. Varsayılanla oynat. Çok büyük havuz: kimse beklemedi, veritabanı boğuldu.
2. Havuzu “formülden” yap. Dengeli.
3. Durumu “yavaş dış çağrı” yap. Veritabanı boşta, istekler timeout alıyor.
4. Havuzu büyüt. Timeout gitti, açık transaction’lar birikti.
5. Formüle dön ve “kök nedeni düzelt”i aç. Denge geri geldi.

Bağlantıyı kim tutuyor?

Havuzun boyutu kadar önemli olan, her bağlantının ne kadar süre tutulduğudur. İki klasik suçlu var:

• Transaction içinde dış çağrı: HTTP isteği beklenirken bağlantı da, transaction da açık kalır.
• Bağlantı sızıntısı?Terimin tanımını açbağlantı sızıntısıHavuzdan alınan bir bağlantının iade edilmemesi. Her sızıntı havuzu bir bağlantı küçültür; sonunda bütün istekler bağlantı beklerken timeout alır.Sözlükte gör →: bir hata yolu bağlantıyı iade etmez; havuz yavaş yavaş boşalır.

HikariCP’de leakDetectionThreshold, belirli bir süreden uzun tutulan bağlantıyı alan kod satırını log’a yazar. hikaricp.connections.pending ve active metrikleri de havuzun ne kadar dolu olduğunu gösterir.

Bir bankanın para transferi servisine bakalım. Para çıkmadan önce bir fraud servisine sorulur; o cevabı beklerken bağlantının nerede olduğu, bütün farkı yaratıyor.

1
spring:
2
  datasource:
3
    hikari:
4
      maximum-pool-size: 10             # start from (cores x 2) + disks, then measure
5
      connection-timeout: 30000         # ms a request may wait for a free connection (default)
6
      leak-detection-threshold: 10000   # logs the stack trace of code holding one longer than this

1
record TransferRequest(String fromIban, String toIban, BigDecimal amount,
2
                       Currency currency, String reference) {}
3

4
@Service
5
class TransferService {
6

7
    private final FraudClient fraud;
8
    private final TransferPosting posting;
9

10
    TransferService(FraudClient fraud, TransferPosting posting) {
11
        this.fraud = fraud;
12
        this.posting = posting;
13
    }
14

15
    // Not @Transactional: the slow HTTP call runs with no connection borrowed.
16
    TransferResult send(TransferRequest req) {
17
        FraudDecision decision = fraud.check(req);
18
        if (decision.rejected()) {
19
            return TransferResult.rejected(decision.reason());
20
        }
21
        return posting.post(req);   // a separate bean, so its @Transactional proxy applies
22
    }
23
}

1
@Component
2
class TransferPosting {
3

4
    private final AccountRepository accounts;
5
    private final LedgerRepository ledger;
6

7
    TransferPosting(AccountRepository accounts, LedgerRepository ledger) {
8
        this.accounts = accounts;
9
        this.ledger = ledger;
10
    }
11

12
    // The connection is borrowed here and returned at commit: only database work inside.
13
    @Transactional
14
    public TransferResult post(TransferRequest req) {
15
        Account from = accounts.lockByIban(req.fromIban());      // SELECT ... FOR UPDATE
16
        from.debit(req.amount(), req.currency());                // throws if balance or limit is short
17
        ledger.save(LedgerEntry.debit(from, req));
18
        ledger.save(LedgerEntry.credit(req.toIban(), req));
19
        return TransferResult.accepted(req.reference());
20
    }
21
}

1
// Works fine at low traffic. Under load, look at what the connection does meanwhile.
2
@Transactional
3
public TransferResult send(TransferRequest req) {
4
    Account from = accounts.lockByIban(req.fromIban());   // connection borrowed, row locked
5

6
    // While the fraud service answers, the connection sits idle and the account row
7
    // stays locked. With ten slow answers in flight the pool is empty, and the next
8
    // transfer waits connectionTimeout even though the database has nothing to do.
9
    FraudDecision decision = fraud.check(req);
10
    if (decision.rejected()) {
11
        return TransferResult.rejected(decision.reason());
12
    }
13

14
    from.debit(req.amount(), req.currency());
15
    ledger.save(LedgerEntry.debit(from, req));
16
    ledger.save(LedgerEntry.credit(req.toIban(), req));
17
    return TransferResult.accepted(req.reference());
18
}

Tuzaklar

Timeout’a havuz büyüterek cevap vermek. Kök neden yavaş bir sorgu ya da dış çağrıysa, büyük havuz sorunu veritabanına taşır.

Otomatik ölçeklenen pod’lar. Pod sayısı iki katına çıkınca bağlantı sayısı da iki katına çıkar; veritabanının sınırı değişmez.

PgBouncer?Terimin tanımını açPgBouncerPostgreSQL önünde çalışan hafif bir bağlantı havuzu. Çok sayıda istemci bağlantısını az sayıda sunucu bağlantısına paylaştırır.Sözlükte gör → transaction modu. Çok sayıda istemciyi az sayıda bağlantıya böler; ama oturuma bağlı özellikler (SET, advisory lock, bazı sürümlerde prepared statement) beklendiği gibi çalışmayabilir.

Bağlantıyı elle almak. DataSource.getConnection() ile alınan bağlantı try-with-resources ile kapatılmazsa, ilk exception onu sızdırır.

Kendini sına