Programming ∀
Ir al canal en Telegram
Ushbu kanalda IT va Dasturlashga aloqador mavzularda subyektiv fikrlarimni bayon qilaman.
Mostrar más1 217
Suscriptores
Sin datos24 horas
-87 días
-3530 días
Archivo de publicaciones
1 217
Agar biz eng pikga chiqaramiz desak. DB engine va FS magicni ishlatish kerak.
Mongodb misolida manashu yerdan direction olsangiz bo'ladi.
Performance monitoring and tuning bo'limiga kirasiz. Aniq esimda yo'q ammo bazi FS related narsalarni async apilarga o'tkazsangiz yanayam zo'r bo'ladi.
https://source.wiredtiger.com/develop/programming.html
1 217
Hullas cooking perfomance mavzusida shunaqa narsalar yozib tursam bo’lar ekan-a linux esimdan chiqib ketyabti bekorga🥲
1 217
Endi yana bir ishni ohiriga yetkazaylik FS tanaladikmi demak uniyam tune qilish kerak 😁
Kegin RAMni ham qilsak bo'ladi. Lekin man memoryda bunaqa narsalar qilib ko'rmadim hali. Chunki memory latency doyim ham sezilmaydi agar in-memory oriented bo'lmasa. Oma lekin biroq buniyam sinasak bo'ladi faqat aniqroq usecase kerak. Uning uchun esa memoryni to'liq diagnostics qilish kerak bilamizki bu birmuncha azob memory dumplar doyim ham yordam bermaydi. Perfda ham doyim ham olib bo'lmaydi hamma parametrlarni. Chunki nimadirni yaxshi qilaman deb boshqa applaringizni buzib qo'yishiz mumkin. Maksimum cachemisslarni kamaytirish choralarini ko'rsangiz ham juda katta impact.
https://blog.svedr.in/posts/filesystem-tuning/
https://cromwell-intl.com/open-source/performance-tuning/file-systems.html
1 217
Ha yana sizni boshizni qotirmaydigan serverless mavzusida ham aniq fikrlarim kam. Chunki uyoqlarda siz hamma narsani ham o’zgartira olmaysiz 🥲
1 217
Bu asosan general purpose DBlar uchun va asosan MongoDB caseda.
Agar RDBMS bo’lsa bazi narsalar mos keladiku lekin aniq javob berolmayman. Sababi ularda Journaling juda ham muhim va vacum kabi narsalar bor. Ammo zerikanda postgresni ham tune qilib ko’ramiz va shunda hulosalarni yozaman.
In-memory, realtime, cache va key-val, vector oriented, graph hullas yana boshqa turdagi DBlar uchun ham taxminan shunaqaroq narsalar bor lekin hammasida doc o’qish kerak va hamma DBga doyim birxil muomila qilolmaysiz 🥲
1 217
Hullas mongoni optimize qilmoqchimidik ?
Eng birinchi target bu albatta FS yani bizni server qanaqa FS da data saqlaydi va I/O operations qiladi.
Albatta bu ancha general masala, shu sababdan quyidagi parametrlarni inobatga olamiz muammo general bo'lgani uchun.
1. Hardware integration. Odatda DBlar uchun SASS yoki HDD ishlatamiz. Lekin xozirda SSDlar ham ommalashyabti lekin barbir hali bu expiremental narsalar shu sabab bizni target o'rtacharoq sifatdagi SASS yoki HDD, aynan kattaroq cache bilan.
2. Perfomance journaling. Biz DB optimization qilmoqchimiz demak bizga journaling masalasi juda muhim.
3. Parallel I/O perfomance, Bizda querylar juda ko'p thread va processlarda execute bo'ladi va bu holatda bizda bottleneck bo'lmasligi kerak aynan FS sababdan
4. Engine cache, ishlatilayotgan DB engineda cacheni configure qilish kerak. Shunda indexlaringizda kamroq cache miss bo'ladi va bu ham ancha yuqori perfomance bo'ladi.
5. Compression, barcha datalar ma'lum compression algorithmlardan foydalanadi bu deyarli hamma Storage enginelarda mavjud. Shu sababdan bizga juda kuchli compress qilmaydigan va kamroq resurs yeydigan compression kerak. Agar kuchli compression bo'lsa DB read osiladi. Agar kuchsiz bo'lsa Storage oshib ketadi va yana DB osilad chunki compression cpu intensiv narsai.
6. Storage journaling configs. Bu masala juda actual masalan har bir logical DB uchun alohida volume qilishingiz mumkin bu aynan sizdagi Disk I/O latencyni yaxshilab beradi. Buning uchun turli uslublar bor masalan Full Database per folder or database per foler and index per foler. Buni ham reserch qilib doclarni o'qish kerak sababi masalan indexlarni SSDda va Datani HDDda saqlasa bo'ladi.
7. Network compression. Barcha network I/O datalar compressed bo'lgani yaxshi.
Hullas birmuncha umumiy masalalar shu. Qolganlari aynan siz qanaqa data saqlashingiz va aynan qanday operationlar oriented ekaniga bog'liq. Masalan agar sizda write oriented bo'lsa ZFS kabi FSlar zo'r.
Agar hammasini tog'ri qilsangiz sizning DB anchagina tez ishlaydi mani holatimda bazi narsalardagi eng yomon perfomance ham 20-30% bo'lgan edi. Eng yaxshi holatda esa 2-3x ))
1 217
Ko’p shaxsiyatli bo’lib qolyabman.
FP, Haskell, Nix
Procedural OO, (ts,node, etc…), kubernetes
Traditional DevOps
1 217
Ops mavzularidan koryera uchun yaxshi direction beradi ko’pchilikga.
https://www.youtube.com/watch?v=X8S3Z_cMIJ4
1 217
Aytgancha Vitaliy amakining yangi videolari chiqibti effectlar haqida. Doyimgidek juda ham zo'r talk.
https://www.youtube.com/watch?v=FO8xXYBMZ8U
1 217
Mongodb uchun wiredTiger tunninglariga misollar bu yerda.
https://source.wiredtiger.com/2.0.1/tuning.html
1 217
Va nihoyat DevOps degan terminalogy aniqlasha boshlabti.
Bu yaxshi yangiliklar, Ha aytgancha bugun biroz research qildim Ops qayerga qarab ketayotgani va bu mavzuda leaderlar nimalar qilishvotgani haqida.
Bu yil DevOps paydo bo'lganiga 15 yil bo'ldi ))
1 217
Bundan svollariz bo'lsa commentga qoldiring balki mongo uchun FS o'zgartirish va storage engine optimizationlarni ham yozib ketarman.
Aniq benchmarklar qilmaganman lekin o'qigan joylarim va tajribamdan kelib chiqib yozaman.
1 217
Buni atay tashadim, hammaga tushunarli bo’lganidan kegin bilasiz qayerga publish qilishimni 🌚
1 217
Savollar bo’lsa qoldiring, mongodb replicaset configuration qilish haqida guide yozdim.
https://gist.github.com/lambdajon/a8a4073339eed06b0ed04bf0eb4d5691
1 217
gitlab feuturelarini ishlatmaganimga ancha bo'lgan edi. DevOps stuff ancha narsalar qo'shilibtiku ))
Xozircha faqat wiki pagelar va PR templatelarni tayyorlavoman. Tasurotlar ajoyib Ops agnostic fichlar ko'pligi ishizni ancha oson qiladida.
