Etkinlik icin tekrar tesekkurler Murat’a. Hem bilgilendirici hem de dinlemesi oldukca keyifli bir sunumdu.
@yasar 'in ricasi uzerine, soru-cevap bolumunde paylastigim, gecen sene yasadigimiz problemi aciklayayim ben de konuyla ilgisi dolayisiyla. Ozellikle Murat’in konusmasinda paylastigi deneme / yanilma kismi ve etkileri bolumunde bahsettigi gibi process ve thread’lerin kaynaktan fazla olmasi durumunda neler oldugunu gostermesi acisindan faydali olabilir.
2021 yili ilk ceyregi sonlarinda web dynolarinda asagidaki gibi bir memory sorunuyla karsilasmaya basladik. Uygulama ilk ayaklandiginda bir sorun yasamiyor ancak ogle saatlerinde musterilerin uygulamayi kullanmaya baslamasi ile birlikte memory tuketimi bir anda tirmanip cokca “Error R14 (Memory quota exceeded)” olusturuyordu. Burada bahsetmem gerekir ki uygulamaya gelen istek sayisinda o donemlerde kayda deger bir degisiklik yoktu.
Detaylari gorebilmek icin Newrelic, Skylight ve Scout APM gibi toollar ile uygulamayi izledigimizde her bir islem icerisindeki memory kullanimi normal gorunuyor, leak olusturabilecek bir allocation bulunmuyordu.
Daha sonra tek tek son donemde yapilmis versiyon guncellemelerine bakarken Puma 4.3’den 5.2 gecis sirasinda Puma’nin davranisinin degistigini farkettik. Puma 5.0-Upgrade dokumaninda yazan memory sorunu bizim durumumuzda da yasanmis oldu.
Note: Puma 5 now automatically uses WEB_CONCURRENCY env var if set see this post for an explanation. If your memory use goes up after upgrading to Puma 5 it indicates you’re now running with multiple workers (processes). You can decrease memory use by tuning this number to be lower.
Eski versiyonda 1 worker 10 thread calisirken WEB_CONCURRENCY degiskenini worker olarak kullanmaya baslayinca bir anda 5 worker x 10 thread olarak ayaklanmaya basladi uygulama. Asagidaki Puma’nin 5.2 gecisimizle birlikte gonderdigi logu gorebilirsiniz
app/web.1 [3] Puma starting in cluster mode...
app/web.1 [3] * Puma version: 5.2.2 (ruby 3.0.0-p0) ("Fettisdagsbulle")
app/web.1 [3] * Min threads: 10
app/web.1 [3] * Max threads: 10
app/web.1 [3] * Environment: production
app/web.1 [3] * Master PID: 3
app/web.1 [3] * Workers: 5
app/web.1 [3] * Restarts: (✔) hot (✖) phased
app/web.1 [3] * Preloading application
5 worker x 10 thead 1 GB’lik 2X Heroku dyno’sunu doldurmak icin hayli yeterli bir sayi 
Uygulamada bir anda memory artisi yasanmasinin sebebi, musteri gelisi sonrasi yeni worker ve threadlerin tetiklenmesi.
Worker (2) ve thread (5) duzenlemesi sonrasi memory kullanimi normale dondu. Bu noktadan sonra @mtoygar 'in dedigi gibi thread sayisini ufak ufak artirarak optimumu bulmaya calistik.
app/web.1 [4] Puma starting in cluster mode...
app/web.1 [4] * Puma version: 5.2.2 (ruby 3.0.0-p0) ("Fettisdagsbulle")
app/web.1 [4] * Min threads: 5
app/web.1 [4] * Max threads: 5
app/web.1 [4] * Environment: production
app/web.1 [4] * Master PID: 4
app/web.1 [4] * Workers: 2
app/web.1 [4] * Restarts: (✔) hot (✖) phased
app/web.1 [4] * Preloading application
