Orb stack machine juda ham zo'r ishlayabti macosda.
Bemalol nixos ishlatsa bo'ladi, bu yerda config:
https://github.com/lambdajon/confs/tree/main/nixos/orb
Bemalol nixos ishlatsa bo'ladi, bu yerda config:
https://github.com/lambdajon/confs/tree/main/nixos/orb
❤1
Faqat shu desktop qo'ymasdan ishlatyabman, yomon emas.
Configim juda bordak bo'lib ketgan o'zi, shu bahona sekin sekin desktop, server va nix-darwinlarni tog'irlab olaman.
Umuman olganda manda nixos muhitlar juda ko'payib boryabti.
Shularni sekin sekin tartiblab joy koyiga keltirish kerak. Main devayslarim configlari ~37GB bo'lgan tag'inam bazi narsalar qo'shilmagan.
Configim juda bordak bo'lib ketgan o'zi, shu bahona sekin sekin desktop, server va nix-darwinlarni tog'irlab olaman.
Umuman olganda manda nixos muhitlar juda ko'payib boryabti.
Shularni sekin sekin tartiblab joy koyiga keltirish kerak. Main devayslarim configlari ~37GB bo'lgan tag'inam bazi narsalar qo'shilmagan.
Macosda qiziq muammo mavjud.
Masalan xozir manda N ta servis ishlayabti deylik va memory 60% turibti.
Ammo macbook zaryadi o'chib qoldi va qayta zaryadga qo'yib yoqdim albatta snapshotlardan recover qilinadi va hammasi qayta tiklanadi.
Tizim o'chib yongani bilan hechnima kill bo'lib ketmaydi. Ammo qiziq tomoni shundaki manashu voqeadan kegin macos 80-90% memory sarflashi mumkin.
Bu yerda potensial sabablar ko'p, lekin aynan ARM processorlarli macbooklarda manashunaqa narsa ko'p kuzatiladi.
Bu masalada aniq texnik argumentlarga ega emasman, lekin qiziq holataq chunki bu narsani doyim kuzatganman.
Masalan xozir manda N ta servis ishlayabti deylik va memory 60% turibti.
Ammo macbook zaryadi o'chib qoldi va qayta zaryadga qo'yib yoqdim albatta snapshotlardan recover qilinadi va hammasi qayta tiklanadi.
Tizim o'chib yongani bilan hechnima kill bo'lib ketmaydi. Ammo qiziq tomoni shundaki manashu voqeadan kegin macos 80-90% memory sarflashi mumkin.
Bu yerda potensial sabablar ko'p, lekin aynan ARM processorlarli macbooklarda manashunaqa narsa ko'p kuzatiladi.
Bu masalada aniq texnik argumentlarga ega emasman, lekin qiziq holataq chunki bu narsani doyim kuzatganman.
💯5✍1⚡1🔥1
Bizni crash detector aynan bazi caselarni detect qila boshladi, masalan coredumplar.
Ammo servislar fail bo'lgani kabi masalalarga yozgan handlerlarimiz kutganimizdek ishlamadi, kegin journaldan hamma datani ovolib shu bilan ishlashni uni analiz qilishni boshladim.
Kegin kutilmagan narsani ko'rdim, ishlab turgan nixos based distrodagi journalda man kutganimdan ham ko'proq fieldlar bor ekan. Bunisi yetarlicha surpriz bo'ldi sababi o'ylaganimdan juda ko'p va turli devayslarda turlicha fieldlar bor.
Birnechta devayslardan dataset to'plab ularga parser yozdim, kegin bazi narsalarni analiz qilib ko'rdim masalan manashu journalda mavjud barcha fieldlar...
Albatta parserlar bilan birnechta narsalarni analiz qildim, ammo savollar ko'paygan sayin muammolar ham ko'paydi.
1. Har bir ideyani tekshirgani yoki savolga javob topgani alohida code yozish kerak.
2. Bazi narsalar natijasini olish uchun yoziladigan kodlar optimal bo'lmagani uchun uzoq kutish kerak ayniqsa 1GB log faylar bo'lsa.
Qisqasi, qarsasam uje DB yozib qo'yabman.
Ha, kegin journaldan olingan dumplar contentlarini tog'ri mongodbga yozdim. Mongodbdab schema generate qivolib bazi fieldlarga indexlarni tiqdim bunga alohida sodda index generator yozvordim.
Shu bilan xozir 1mln documentlik journalarni dbdan bemalol aggregate qilolyabman, bu narsa esa asosan turli edge caselar, turlicha catch senariylar qilish uchun kerak.
Masalan xozir systemd qanday dasturlani manage qilgan ?
Qaysi dasturlarda muammolar sodir bo'lgan ?
Kernel scopeda qanday muammolar sodir bo'lgan ?
Falon dasturda errorlar sodir bo'lganmi ?
Hullas manashunaqa savollarga ancha tez javob olyabman.
Endi ushbu savollar problem detection case bo'lib xizmat qiladi codega o'girilsa bo'lgani ))
Ammo servislar fail bo'lgani kabi masalalarga yozgan handlerlarimiz kutganimizdek ishlamadi, kegin journaldan hamma datani ovolib shu bilan ishlashni uni analiz qilishni boshladim.
Kegin kutilmagan narsani ko'rdim, ishlab turgan nixos based distrodagi journalda man kutganimdan ham ko'proq fieldlar bor ekan. Bunisi yetarlicha surpriz bo'ldi sababi o'ylaganimdan juda ko'p va turli devayslarda turlicha fieldlar bor.
Birnechta devayslardan dataset to'plab ularga parser yozdim, kegin bazi narsalarni analiz qilib ko'rdim masalan manashu journalda mavjud barcha fieldlar...
Albatta parserlar bilan birnechta narsalarni analiz qildim, ammo savollar ko'paygan sayin muammolar ham ko'paydi.
1. Har bir ideyani tekshirgani yoki savolga javob topgani alohida code yozish kerak.
2. Bazi narsalar natijasini olish uchun yoziladigan kodlar optimal bo'lmagani uchun uzoq kutish kerak ayniqsa 1GB log faylar bo'lsa.
Qisqasi, qarsasam uje DB yozib qo'yabman.
Ha, kegin journaldan olingan dumplar contentlarini tog'ri mongodbga yozdim. Mongodbdab schema generate qivolib bazi fieldlarga indexlarni tiqdim bunga alohida sodda index generator yozvordim.
Shu bilan xozir 1mln documentlik journalarni dbdan bemalol aggregate qilolyabman, bu narsa esa asosan turli edge caselar, turlicha catch senariylar qilish uchun kerak.
Masalan xozir systemd qanday dasturlani manage qilgan ?
Qaysi dasturlarda muammolar sodir bo'lgan ?
Kernel scopeda qanday muammolar sodir bo'lgan ?
Falon dasturda errorlar sodir bo'lganmi ?
Hullas manashunaqa savollarga ancha tez javob olyabman.
Endi ushbu savollar problem detection case bo'lib xizmat qiladi codega o'girilsa bo'lgani ))
Programming ∀
Bizni crash detector aynan bazi caselarni detect qila boshladi, masalan coredumplar. Ammo servislar fail bo'lgani kabi masalalarga yozgan handlerlarimiz kutganimizdek ishlamadi, kegin journaldan hamma datani ovolib shu bilan ishlashni uni analiz qilishni…
Journaldan olingan datani compress qilib ko'rdik
Compression deyarli 10x resize qilyabti manashu datani olishga taxminan 20s vaqt ketyabti.
Agar best compression qiladigan bo'lsak unda 15x dan ko'proq resize qilyabti ammo 30s ketyabti.
Code hali optimal emas shunchaki prototip bo'lib yotibti agar shularni optimization qilsak xozirgi 20s taxminan 15s bo'lsa kerak yana bilmadim ))
Compression deyarli 10x resize qilyabti manashu datani olishga taxminan 20s vaqt ketyabti.
Agar best compression qiladigan bo'lsak unda 15x dan ko'proq resize qilyabti ammo 30s ketyabti.
Code hali optimal emas shunchaki prototip bo'lib yotibti agar shularni optimization qilsak xozirgi 20s taxminan 15s bo'lsa kerak yana bilmadim ))
Telekom kompaniyalari ajoyibda.
Huddi hechqanday malumotga ega bo’lmaganlardek 8-martda erkaklarni 14-yanvarda ayollarni ham tabriklayveradi. Bu bilan miyig’ida aytishadi: sizni hechkim kuzatmayabti.
Huddi hechqanday malumotga ega bo’lmaganlardek 8-martda erkaklarni 14-yanvarda ayollarni ham tabriklayveradi. Bu bilan miyig’ida aytishadi: sizni hechkim kuzatmayabti.
🤣23