Programming ∀

I love this comment style. Tosh davrida yashagan ekanman.

DevOps yechimlar kerak bo'lsa kelinouradi. Hudoholasa birnecha oydan kegin hammasi tayyor bo'ladi bizda 😎 Loyihangiz yashaydigan zooparkni obodonlashtirib beramiz😊

Based, FPga jiddiyroq kirisha boshlaganimdan kegin Gof, SOLID, Grasp kabi narsalar o’rniga boshqalari keldi va bu conceptlar avvalaridan ancha effective🙂

100%

Bazi narsalarda learning curve sal murakkab bo’layotganini sezdim. Endi notes yozishni odat qilaman self-hosted obsidian va tamam. Va hafta yakunida 1 haftalik notesni qayta o’qiyman.

Microsoft MVP - Most Valaki-salaki Programmer

Point of views - Juda qiziq narsa kuzatganman odatda biror muammoga turli soha vakillari turlicha qarashadi va yechim o'ylashadi. Kecha huddi shunaqa hodisalardan biri bo'ldi. Hullas birqancha dunyoqarashlar va o'rtada aniq konsensus yo'q. Huddiki hamma o'z fikrini o'tkazishga xarakat qilayotgandak. Asilda muammo qolib insonlar bir birlariga qarshi chiqa boshlashdi. Yeg'ilish real hayotda bo'lgani uchun ham bunaqa baxs munozara judayam hunik va bordak bo'la boshladi. Turli dunyoqarash va maqsadli odamlar bir mavzuni discussion qilishi haqiqiy bordakga sabab bo'ldi, toki biroz sovuqqonlik bilan yondoshib hamma aynan bir muammoni hal qilish uchun yegi'lganini hisobga olmaguncha. Manashu suxbatda tushunib yetdim hissiyotlar bilan boshqaruv yoki hissiyotlar bilan qaror qilish umuman bo'lmaydigan narsa. Albatta o'sha davrada turli kasb egalari bor edi, va shu sababdan dunyoqarashlar gradienti sezilib turadi ammo ma'lum toifa odamlarda nafaqat hissiyotga asoslangan yechimlarni balki o'zlari hohlayotgan(o'zlariga moslangan) yechimlarni ham kuzatdim. Hullas muammo barbir hal bo'lmadi 1 soatga yaqin munozara bo'ldi. Kegin taklif berdim qog'oz va ruchkani olib bitta tablega hammaning qisqa fikri va dalilini yozib oldik, kegin boshqa joyga anashu dalillarni hammasini ranked qilib chiqdik prooflarga nisbatan. Kegin har bir dalilni tanqid qildik yani qarshi argumentlar, ana kegin qarshi argumentlarni proof qildik va rank qildik. Manashu itarationdan kegin barcha hissiy fikrlar va yechimlar chetga chiqib ketti. Ohiri 2-3 fikr qoldi. Qolgan fikrlar uchun asosiy contextni topib suxbatni davom qildik. Boshida hamma ishonmagan edi ammo aynan manashu yechim hammani qoniqtirdi va jamoaviy firklashga asoslangan yechimga keldik. Man esa juda hursand bo'ldim sababi birnecha daqiqa oldin bo'layotgan molxona haqiqiy ilmiy majlisga aylandi(Devanniy expertlar majlisi). Eng muhimi muammo yechimi topildi discussion ancha adekvatlashdi.

Lol.

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

Hullas cooking perfomance mavzusida shunaqa narsalar yozib tursam bo’lar ekan-a linux esimdan chiqib ketyabti bekorga🥲

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

Ha yana sizni boshizni qotirmaydigan serverless mavzusida ham aniq fikrlarim kam. Chunki uyoqlarda siz hamma narsani ham o’zgartira olmaysiz 🥲

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 🥲

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 ))

Ko’p shaxsiyatli bo’lib qolyabman. FP, Haskell, Nix Procedural OO, (ts,node, etc…), kubernetes Traditional DevOps

Ops mavzularidan koryera uchun yaxshi direction beradi ko’pchilikga. https://www.youtube.com/watch?v=X8S3Z_cMIJ4

Optimization qilamiz hammasini va shard qilamiz )

Aytgancha Vitaliy amakining yangi videolari chiqibti effectlar haqida. Doyimgidek juda ham zo'r talk. https://www.youtube.com/watch?v=FO8xXYBMZ8U

Keyingisi nima kerak ?

Mongodb uchun wiredTiger tunninglariga misollar bu yerda. https://source.wiredtiger.com/2.0.1/tuning.html