Uzun zamandır kafamda olan bir sorunun cevabını Western Digital'ın web sitesinde dolaşırken buldum. Bütün alışveriş merkezleri, havaalanları vs. girişlerinde güvenlik sebebiyle konulan x ışını cihazlarına manyetik disklerimi bırakma konusunda tereddütlerim vardı. Western Digital'ın bilgisine göre x ışını cihazlarının yaydığı manyetik alan, sabit disklere zarar verebilecek boyutlarda değilmiş.
http://wdc.custhelp.com/app/answers/detail/a_id/1458/related/1/session/L2F2LzIvdGltZS8xMzQ4NjcwMjgzL3NpZC9DRm9ma2Q3bA%3D%3D
Burada anlatılanlar benim küçük/büyük sorunlarımı çözerken izlediğim adımlardır. İlerde bu bilgilere kendim her yerden erişeyim diye, veya benzer sorunları yaşayan başkaları da erişebilsin diye burada biriktiriyorum. Bu adımları uygulamak, hata yapmamak ve doğabilecek herhangi bir hasar sizin kendi sorumluluğunuzdadır. Yazar(lar) veya yazılardaki bağlantıların sahipleri hiçbir şekilde oluşabilecek hata/hasarlardan dolayı sorumlu tutulamazlar.
26.09.2012
6.09.2012
TR/Agent.AWQX.1 Truva Atı (zero day)
Başka bir zararlı kod aktivitesi. Avira Professional Security 12 kurulu bir bilgisayarında Excel.exe'ye virüs bulaştığına dair ekrana çıkan bir uyarı mesajı ile başladı hikaye.
Elbette bu gerçek bir antivirüs yazılımı değil ve Excel.exe'ye virüs bulaştığına dair görüntülenen bu uyarı da gerçekleri yansıtmıyor. Bu pembe tonlara sahip "Live Security Platinum" penceresi sahte; ona şüphe yok. Ama muhtemelen sadece sahte olmakla kalmayacak, bazı zararlı bileşenleri de olacak.
Söz konusu bilgisayarda görev yöneticisinin, process explorer'ıın ve komut satırının açılması engelleniyor. Uzak bir bilgisayardan pslist ile baktığımda ise %ALLUSERSPROFILE%\Application Data klasöründe 32 tane rastgele karakterden oluşan bir isme sahip klasör içinde aynı isimde bir exe dosyasının bu işin sorumlusu olduğunu gördüm. pskill ile sonlandıramadım maalesef. Ama Windows komut satırı aracı taskkill başarılı oldu.
Yukarıdaki resimde görüldüğü gibi sistem tepsisinde Avira'nın simgesi gözüküyor. Yani Avira bu işler olurken çalışıyormuş. Şimdi nasıl oluyor da antivirüs sistemi hiçbirşey yapmıyor diye düşünürken Avira TR/Agent.AWQX.1 tanımlamasıyla virüs bulduğu uyarısını verdi. O zaman yeni sorumuz şu: Niye sisteme bulaşmadan tespit edemedi?
Zararlı kodun adını (TR/Agent.AWQX.1 olarak gözüküyor) kullanarak Google'da yaptığım bir aramada şu an itibariyle kaydadeğer bir sonuç alamadım. Ama AWQX anahtar kelimesi ile yaptığım aramada bunun bir truva atı bileşeni olduğunu, çalıştığı bilgisayarlarda bir arka kapı (backdoor) açtığını, muhtemelen daha fazla zararlı bileşen indirerek bilgisayarı bir botnetin parçası haline getirdiğini öğrendim [1],[2],[3].
Sonra Avira'nın virüs tanımlamalarını (vdf) incelerken 7.11.41.238 numaralı vdf'inde bu virüsün adını gördüm. Avira web sitesinde bu tanımlamanın tam olarak hangi saatte yayınlandığı bilgisini vermiyor maalesef. Ama yerel ağımızdaki AMC Sunucu'nun kayıtlarından 7.11.41.238 numaralı güncellemenin bugün (6 Eylül) saat 4:15'te download edildiğini gördüm. Tahmin ediyorum ki bu güncelleme Avira.com'da saat 01:15-04:15 saatleri arasında yayınlanmış. Yani çok yeni. Kullanıcı sabah bilgisayarını açtıktan bir süre sonra güncellemeyi almış.
Peki acaba bu bilgisayarı kullanan kullanıcımız acaba bu trojanın bulaşmasına sebep olan aktiviteyi ne zaman yapmış? Bugün içinde kayda değer bir trafik gözükmüyordu. Bir önceki günün kayıtlarına baktığımızda bir şüphelimiz oldu: http://ucpbcsyt.justdied.com.
Kesinlikle bu site diyemiyorum ama bir önceki gün bu siteden bazı veri alışveri olmuş ve bu site şu anda McAfee'nin trustedsource.org sitesinde "Malicious Sites" olarak kategorize edilmiş ve yüksek riskli olarak işaretlenmiş.
Yukarıda bahsettiğim All Users\Application Data klasöründeki exe dosyasını sonlandırdıktan,
Çok yeni bir virüstü (zero day) ama Avira yaklaşık 12 saat farkla bir güncelleme yayınladı. Herhangi bir zarar oluşmadan tehdit etkisiz hale getirildi.
Referanslar
[1] www . spywareviruscleaner . com/How-to-Remove-Generic12.AWQX.html
[2] http://www.emsisoft.com/en/malware/?Backdoor.Win32.LolBot.awqx.AMN
[3] http://www.paretologic.com/resources/definitions.aspx?remove=Magania%20Awqx%20Trojan
Elbette bu gerçek bir antivirüs yazılımı değil ve Excel.exe'ye virüs bulaştığına dair görüntülenen bu uyarı da gerçekleri yansıtmıyor. Bu pembe tonlara sahip "Live Security Platinum" penceresi sahte; ona şüphe yok. Ama muhtemelen sadece sahte olmakla kalmayacak, bazı zararlı bileşenleri de olacak.
Söz konusu bilgisayarda görev yöneticisinin, process explorer'ıın ve komut satırının açılması engelleniyor. Uzak bir bilgisayardan pslist ile baktığımda ise %ALLUSERSPROFILE%\Application Data klasöründe 32 tane rastgele karakterden oluşan bir isme sahip klasör içinde aynı isimde bir exe dosyasının bu işin sorumlusu olduğunu gördüm. pskill ile sonlandıramadım maalesef. Ama Windows komut satırı aracı taskkill başarılı oldu.
Yukarıdaki resimde görüldüğü gibi sistem tepsisinde Avira'nın simgesi gözüküyor. Yani Avira bu işler olurken çalışıyormuş. Şimdi nasıl oluyor da antivirüs sistemi hiçbirşey yapmıyor diye düşünürken Avira TR/Agent.AWQX.1 tanımlamasıyla virüs bulduğu uyarısını verdi. O zaman yeni sorumuz şu: Niye sisteme bulaşmadan tespit edemedi?
Zararlı kodun adını (TR/Agent.AWQX.1 olarak gözüküyor) kullanarak Google'da yaptığım bir aramada şu an itibariyle kaydadeğer bir sonuç alamadım. Ama AWQX anahtar kelimesi ile yaptığım aramada bunun bir truva atı bileşeni olduğunu, çalıştığı bilgisayarlarda bir arka kapı (backdoor) açtığını, muhtemelen daha fazla zararlı bileşen indirerek bilgisayarı bir botnetin parçası haline getirdiğini öğrendim [1],[2],[3].
Sonra Avira'nın virüs tanımlamalarını (vdf) incelerken 7.11.41.238 numaralı vdf'inde bu virüsün adını gördüm. Avira web sitesinde bu tanımlamanın tam olarak hangi saatte yayınlandığı bilgisini vermiyor maalesef. Ama yerel ağımızdaki AMC Sunucu'nun kayıtlarından 7.11.41.238 numaralı güncellemenin bugün (6 Eylül) saat 4:15'te download edildiğini gördüm. Tahmin ediyorum ki bu güncelleme Avira.com'da saat 01:15-04:15 saatleri arasında yayınlanmış. Yani çok yeni. Kullanıcı sabah bilgisayarını açtıktan bir süre sonra güncellemeyi almış.
Peki acaba bu bilgisayarı kullanan kullanıcımız acaba bu trojanın bulaşmasına sebep olan aktiviteyi ne zaman yapmış? Bugün içinde kayda değer bir trafik gözükmüyordu. Bir önceki günün kayıtlarına baktığımızda bir şüphelimiz oldu: http://ucpbcsyt.justdied.com.
Kesinlikle bu site diyemiyorum ama bir önceki gün bu siteden bazı veri alışveri olmuş ve bu site şu anda McAfee'nin trustedsource.org sitesinde "Malicious Sites" olarak kategorize edilmiş ve yüksek riskli olarak işaretlenmiş.
Yukarıda bahsettiğim All Users\Application Data klasöründeki exe dosyasını sonlandırdıktan,
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runaltında bu exe dosyasına işaret eden ve sistem tekrar başladığında çalışmasını sağlayacak girişi de sildikten sonra Avira'nın 7.11.41.242 (daha da yeni) virüs tanım dosyası ile tarama yaptım. Birşey bulamadıktan sonra dosya kapandı.
Çok yeni bir virüstü (zero day) ama Avira yaklaşık 12 saat farkla bir güncelleme yayınladı. Herhangi bir zarar oluşmadan tehdit etkisiz hale getirildi.
Referanslar
[1] www . spywareviruscleaner . com/How-to-Remove-Generic12.AWQX.html
[2] http://www.emsisoft.com/en/malware/?Backdoor.Win32.LolBot.awqx.AMN
[3] http://www.paretologic.com/resources/definitions.aspx?remove=Magania%20Awqx%20Trojan
17.08.2012
Avira Server Security 12 SP1
Daha önce Avira'nın hem Avira Professional Security 12 hem de Avira Server Security 12 ürünleri için service pack 1'i yayınlayacağını yazmıştım. Service Pack yayınlandı, Avira Management Console'da (AMC) gözüktü. Ağdaki Avira Professional Security 12 ürünü yüklü olan PC'lere otomatik olarak yeni sürüm yüklendi. Ama sunucularımda bu geçiş olmayınca duruma müdahale etmem gerekti.
Daha önce AMC'nin loglarında Avira Server Security 12 için de 12.0.0.2309 sürümün download edildiğini gördüğüm için elimde güncel sürümün olduğundan emin bir şekilde sunucuları elle güncellemek istedim. Ama fayda etmedi. Sunucular, AMC Server üzerinde yeni sürümün olmadığını söyleyerek güncellemeyi reddediyorlardı.
Hemen Avira Update Manager (AUM) altındaki Released Products kısmına giderek Avira Server Security 12 ürününün sürümünü kontrol ettim ve farkettim ki burada bir sorun var.
Görüldüğü gibi sürüm N/A (Not Available) olarak gözüküyor. Download edilmiş kurulum paketi ile ilgili bir sorun olabilir mi düşüncesiyle %ALLUSERSPROFILE%\Application Data\Avira\Avira Security Management Server\Softaware\751 klasörünün altındaki kurulum paketine baktım (hatta onu sunuculardan birine kurdum) ve sürümün 12.0.0.2309 olduğunu gördüm. Sorun burada değil.
AUM'un altındaki Released Products'ta listelenen Avira Server Security 12'yi silip tekrar eklemek istedim, ama böyle bir seçeneğim yoktu. Sonradan öğrendim ki AMC'de Configuration'ın altında Update arayüzündeki "Automatically syncronize software repositories between AMC and AUM servers" checkbox'ını işaretinin kaldırılarak silme işlemi mümkün olabiliyor.
Bu şekilde Avira Server Security 12'yi silip tekrar ekledim, ama bu da çözüm olmadı. Bir süre sonra Avira Türkiye Destek'ten aldığım bilgiye göre Avira, sunucu ürünleri için SP1'li ürünü dağıtmayı geçici olarak durdurmuş.
Yine hiçbir yerde hiçbir açıklama yok, bilgilendirme yok. AMC'nin içine Info Center diye bir bölüm koymuşlar. Çok güzel. SP1'in yayınlanacağı bilgisi de zaten *sadece* burada çıktı. Ama olumsuz bilgiler hiç paylaşılmıyor. Çok gizli bilgilere erişmek için illa ki kırmızı hattı kullanmak zorundayız.
Daha önce AMC'nin loglarında Avira Server Security 12 için de 12.0.0.2309 sürümün download edildiğini gördüğüm için elimde güncel sürümün olduğundan emin bir şekilde sunucuları elle güncellemek istedim. Ama fayda etmedi. Sunucular, AMC Server üzerinde yeni sürümün olmadığını söyleyerek güncellemeyi reddediyorlardı.
Hemen Avira Update Manager (AUM) altındaki Released Products kısmına giderek Avira Server Security 12 ürününün sürümünü kontrol ettim ve farkettim ki burada bir sorun var.
Görüldüğü gibi sürüm N/A (Not Available) olarak gözüküyor. Download edilmiş kurulum paketi ile ilgili bir sorun olabilir mi düşüncesiyle %ALLUSERSPROFILE%\Application Data\Avira\Avira Security Management Server\Softaware\751 klasörünün altındaki kurulum paketine baktım (hatta onu sunuculardan birine kurdum) ve sürümün 12.0.0.2309 olduğunu gördüm. Sorun burada değil.
AUM'un altındaki Released Products'ta listelenen Avira Server Security 12'yi silip tekrar eklemek istedim, ama böyle bir seçeneğim yoktu. Sonradan öğrendim ki AMC'de Configuration'ın altında Update arayüzündeki "Automatically syncronize software repositories between AMC and AUM servers" checkbox'ını işaretinin kaldırılarak silme işlemi mümkün olabiliyor.
Bu şekilde Avira Server Security 12'yi silip tekrar ekledim, ama bu da çözüm olmadı. Bir süre sonra Avira Türkiye Destek'ten aldığım bilgiye göre Avira, sunucu ürünleri için SP1'li ürünü dağıtmayı geçici olarak durdurmuş.
Yine hiçbir yerde hiçbir açıklama yok, bilgilendirme yok. AMC'nin içine Info Center diye bir bölüm koymuşlar. Çok güzel. SP1'in yayınlanacağı bilgisi de zaten *sadece* burada çıktı. Ama olumsuz bilgiler hiç paylaşılmıyor. Çok gizli bilgilere erişmek için illa ki kırmızı hattı kullanmak zorundayız.
13.08.2012
IFrame zararlı kodları
McAfee kullanırken varlıklarından bile haberim yoktu. Avira kullanmaya başladıktan sonra ne kadar çok olduklarını farkettim. Bir süre öncesine kadar internette güvenli gezinmenin, güvenli web sitelerini ziyaret etmekten ibaret olduğu gibi bir fikrim vardı. Ancak son zamanlarda normal şartlar altında güvenli sayılabilecek bazı web sitelerinin bile bazı zararlı kodlar barındırabildiğini gördüm.
Birçok örnek var, ama Türkiye Masa Federasyonu'nun sitesi bir gov.tr sitesi olması açısından önemli bir örnek. Kullanıcılarımızdan birisinin www.tmtf.gov.tr sitesini ziyaret etmesinin ardından Avira AMC konsoluna düşen virüs uyarıları karşısında şaşırdım. Avira'nın virüs olduğunu düşündüğü dosyayı Avira Merkez'ine tekrar taranmak üzere gönderdim, muhtemelen yanlış alarm olabilir düşüncesiyle. Ama zararlı içerik doğrulandı.
Bundan sonra şu sayfayı buldum. Burada IFrame zararlı kodlarının (onları "badware" olarak adlandırmış) nasıl bulaştığı anlatılmış. Sitenin uzun süre bu zararlı kodların etkisi altında kalmasının sonucunda Google'ın siteyi farketmesi durumunda sitenin ziyaretçilerinin nasıl azalabileceği ve saygınlığını nasıl kaybedebileceği de anlatılmış. Bir sitenin Google tarafından karalisteye alınıp alınmadığını, son 90 günlük aktivitenin sonucunun ne olduğunu aşağıdaki adresten öğrenebiliriz.
Ek (2019-12-10): Güncel adres:
Google bir siteyi karalisteye alınca ne oluyor? Yeni tarayıcılar Google tarafından yönetilen bu veritabanını periyodik olarak inceleyip bu veritabanındaki sitelerden birine erişilmek istendiğinde şöyle bir uyarı sayfası gösterebiliyorlar:
Birçok örnek var, ama Türkiye Masa Federasyonu'nun sitesi bir gov.tr sitesi olması açısından önemli bir örnek. Kullanıcılarımızdan birisinin www.tmtf.gov.tr sitesini ziyaret etmesinin ardından Avira AMC konsoluna düşen virüs uyarıları karşısında şaşırdım. Avira'nın virüs olduğunu düşündüğü dosyayı Avira Merkez'ine tekrar taranmak üzere gönderdim, muhtemelen yanlış alarm olabilir düşüncesiyle. Ama zararlı içerik doğrulandı.
Bundan sonra şu sayfayı buldum. Burada IFrame zararlı kodlarının (onları "badware" olarak adlandırmış) nasıl bulaştığı anlatılmış. Sitenin uzun süre bu zararlı kodların etkisi altında kalmasının sonucunda Google'ın siteyi farketmesi durumunda sitenin ziyaretçilerinin nasıl azalabileceği ve saygınlığını nasıl kaybedebileceği de anlatılmış. Bir sitenin Google tarafından karalisteye alınıp alınmadığını, son 90 günlük aktivitenin sonucunun ne olduğunu aşağıdaki adresten öğrenebiliriz.
http://www.google.com/safebrowsing/diagnostic?site=http://www.site-adi.com.tr
Ek (2019-12-10): Güncel adres:
https://transparencyreport.google.com/safe-browsing/search?url=siteadi.com.tr
Burada en sondaki site='dan sonra gelen adresi istediğiniz şekilde değiştirerek merak ettiğiniz bir sitenin son 90 günlük raporuna ulaşabilirsiniz.Google bir siteyi karalisteye alınca ne oluyor? Yeni tarayıcılar Google tarafından yönetilen bu veritabanını periyodik olarak inceleyip bu veritabanındaki sitelerden birine erişilmek istendiğinde şöyle bir uyarı sayfası gösterebiliyorlar:
Google Chrome
Mozilla Firefox
Bu seçenekler Google'ın sunduğu Safe Browsing[1] hizmeti ile geliyor ve varsayılan olarak tarayıcılarda etkinleştirilmiş durumda. Firefox'ta bu ayarlara Seçenekler>Güvenlik sekmesinde ulaşılıyor. Google Chrome'da ise Seçenekler>Gelişmiş Seçenekleri Göster>Gizlilik altında.
Referanslar:
[1] Google Safe Browsing Protocol v2 : http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
2.08.2012
Avira Service Pack-1
Avira'nın AMC console'unda yer alan InfoCenter'da görüntülenebilen bilgiye göre Avira'nın service pack 1'i 8 Ağustos'a kadar kurulabilir durumda olacakmış. Bu bilgiyi Avira neden web sitesinde paylaşmaz, bilemiyorum. Şimdilik sadece AMC'nin InfoCenter'ında var.
Burada yer alan bilgilere göre şu anda 12.0.0.1466 sürümüne sahip Avira Professional Security 2012 ürününün sürümü 12.0.0.1504'e, şu anda sürümü 12.0.0.2272 olan Avira Server Security 2012'nin sürümü de 12.0.0.2309'a yükseltilecek.
31 Temmuz tarihinde InfoCenter'a düşen bu haberde service pack 1'in piyasaya çıkışının 8 Ağustos'a kadar tamamlanacağı belirtiliyor. Çok sayıda bug'ı düzelteceği söylenmiş. Gerçi açıkça benim ve Avira kullanan binlerce kişinin şu derdine derman olacağı belirtilmemiş ama tüm beklentiler bu yönde.
Burada yer alan bilgilere göre şu anda 12.0.0.1466 sürümüne sahip Avira Professional Security 2012 ürününün sürümü 12.0.0.1504'e, şu anda sürümü 12.0.0.2272 olan Avira Server Security 2012'nin sürümü de 12.0.0.2309'a yükseltilecek.
31 Temmuz tarihinde InfoCenter'a düşen bu haberde service pack 1'in piyasaya çıkışının 8 Ağustos'a kadar tamamlanacağı belirtiliyor. Çok sayıda bug'ı düzelteceği söylenmiş. Gerçi açıkça benim ve Avira kullanan binlerce kişinin şu derdine derman olacağı belirtilmemiş ama tüm beklentiler bu yönde.
1.08.2012
Avira "Bad Image" hatası
McAfee antivirüsü bırakıp Avira'ya geçeli 6 ay oldu. Avira'nın genel performansından gayet memnunum. Ancak Windows Vista ve Windows 7 işletim sistemleri üzerinde bir türlü giderilemeyen bir hatası var. Bilgisayar açıldıktan bir süre sonra Avira güncelleme yapmayı durduruyor. Bunun sonucunda AMC üzerinde bu hatanın olduğu bilgisayar kırmızı ünlem işaretiyle görünmeye başlıyor.
Bu aşamadan sonra AMC üzerinden veya hatanın oluştuğu bilgisayarın konsolundan update yaptırmak mümkün olmuyor. Çünkü Avira'ya ait "About" hariç hiçbir grafik arayüz çalışmaz hale geliyor. Programın grafik arayüzlerine erişme girişimlerinin hepsi aşağıdaki gibi "Bad Image" hatası ile sonlanıyor ve
C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL.dll
konumundaki sistem dosyası ile ilgili bir hatanın olduğundan şikayet ediyor.
Comctl.dll, işletim sistemine ait bir dosya. Bu dosyada olabilecek bir hata, muhtemelen Windows'un daha ciddi hatalar vermesine sebep olurdu. Zaten Avira'nın forumunda açılan şu başlıkta belirtildiği gibi dosyayı tekrar yüklemek de sorunu gidermedi.
Forumda soruna çare olabilecek birkaç yöntemden daha bahsedilmiş ama hiçbirisi gerçek bir katkıda bulunmadı. Mayıs ayında Avira'nın yayınladığı Service Pack 0 da fayda etmedi.
Avira Türkiye sorunun Visual Studio Redistributable sürümleri ile ilgili olduğunu söyledi. Farklı sürümlerin varlığının bu soruna yol açtığını, mümkünse Visual Studio Redistributable'ları ve Avira bileşenlerini kaldırıp kurmamızı önerdi. Ama zaten Avira Professional Security 2012 ve Avira Management Console'u kurmak için Microsoft Visual Studio C++ 2008 Redistributable ve Microsoft Visual Studio C++ 2010 Redistributable bileşenlerinin kurulu olması gerekiyor.
Sorun Windows XP veya Windows Server işletim sistemlerinde görülmüyor. Hedef sadece Windows Vista ve Windows 7. Forumdaki asdasdasd adlı kullanıcının da dediği gibi, 10 aydır çözülemeyen bu sorun gerçekten inanılmaz!
14.08.2012 Ek: Avira Service Pack 0'dan sonra Service Pack 1 de bu sorunu çözemedi. Avira ürün sürümü 12.0.0.1504 olan Windows 7 bir sistem üzerinde bu sorunla hala karşılaşıyorum.
30.04.2013 Ek: 2013 sürümlerinde bu sorun artık yok. Sorun olmadığı bilgisini vermek için acele etmedim. Uzun bir süredir kullanıyorum, artık bu hata giderilmiş.
Bu aşamadan sonra AMC üzerinden veya hatanın oluştuğu bilgisayarın konsolundan update yaptırmak mümkün olmuyor. Çünkü Avira'ya ait "About" hariç hiçbir grafik arayüz çalışmaz hale geliyor. Programın grafik arayüzlerine erişme girişimlerinin hepsi aşağıdaki gibi "Bad Image" hatası ile sonlanıyor ve
C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL.dll
konumundaki sistem dosyası ile ilgili bir hatanın olduğundan şikayet ediyor.
Comctl.dll, işletim sistemine ait bir dosya. Bu dosyada olabilecek bir hata, muhtemelen Windows'un daha ciddi hatalar vermesine sebep olurdu. Zaten Avira'nın forumunda açılan şu başlıkta belirtildiği gibi dosyayı tekrar yüklemek de sorunu gidermedi.
Forumda soruna çare olabilecek birkaç yöntemden daha bahsedilmiş ama hiçbirisi gerçek bir katkıda bulunmadı. Mayıs ayında Avira'nın yayınladığı Service Pack 0 da fayda etmedi.
Avira Türkiye sorunun Visual Studio Redistributable sürümleri ile ilgili olduğunu söyledi. Farklı sürümlerin varlığının bu soruna yol açtığını, mümkünse Visual Studio Redistributable'ları ve Avira bileşenlerini kaldırıp kurmamızı önerdi. Ama zaten Avira Professional Security 2012 ve Avira Management Console'u kurmak için Microsoft Visual Studio C++ 2008 Redistributable ve Microsoft Visual Studio C++ 2010 Redistributable bileşenlerinin kurulu olması gerekiyor.
Sorun Windows XP veya Windows Server işletim sistemlerinde görülmüyor. Hedef sadece Windows Vista ve Windows 7. Forumdaki asdasdasd adlı kullanıcının da dediği gibi, 10 aydır çözülemeyen bu sorun gerçekten inanılmaz!
14.08.2012 Ek: Avira Service Pack 0'dan sonra Service Pack 1 de bu sorunu çözemedi. Avira ürün sürümü 12.0.0.1504 olan Windows 7 bir sistem üzerinde bu sorunla hala karşılaşıyorum.
30.04.2013 Ek: 2013 sürümlerinde bu sorun artık yok. Sorun olmadığı bilgisini vermek için acele etmedim. Uzun bir süredir kullanıyorum, artık bu hata giderilmiş.
2.07.2012
Linux IO monitoring
VMware Server'ın yüklü olduğu linux sistemde kaynak sorunları yaşamamın üzerine sorunun bellek mi, işlemci mi yoksa disk mi olduğunu anlamaya çalıştım. Ama bu kolay olmadı. Window'da aşina olduğum Performans Monitor benzeri bir araç linux server'da yoktu. Bunun için araştırmaya başladım.
Biraz önbilgi. Linux çekirdeği disk IO'yu sayfalara böler. Birçok sistemde varsayılan sayfa boyutu 4K dır ($ getconf PAGESIZE komutu ile çalışan sistemin Page Size boyutunu görebilirsiniz). Linux, fiziksel adres alanı ile eşleştirilen bir "sanal bellek alanı" katmanı kullanır. Bir uygulamanın ihtiyaç duyduğu veri önce CPU cache'inde, daha sonra fiziksel bellekte aranır. Bulunamazsa bir majör sayfa hatası (MPF) oluşur ve aranan veri diskten okunarak RAM'deki tampon belleğe yazılır. Tampon bellekteki verilere erişim çağrıları minör sayfa hatasına (MnPF) sebep olur. MPF'ları azaltıp MnPF'ları artırmak için disk erişimlerinde buffer (yazma işlemleri için ayrılan tampon bellek) ve cache (okuma işlemleri için ayrılan tampon bellek) kullanılır. Bir sistemdeki toplam bellek miktarı, kullanılan bellek, buffer ve cache değerlerini
Bir sistemde üç tip bellek sayfası vardır:
Read Pages: MPF ile diskten okunan sayfalar. Bellekte read-only olarak tutulur. Kütüphane dosyaları gibi hiç değişmeyecek dosyaların ait verileri içerirler. Çekirdek ihtiyaç duydukça bunları kullanır. Bellek sıkıntısı olması durumunda bir kısmı boş olarak işaretlenir, uygulamalar buradaki verilere tekrar ihtiyaç duyduğunda MPF'lerle onları tekrar belleğe getirir.
Dirty Pages: Bu alandaki veriler çekirdek tarafından değiştirilen verilerdir. Değişiklikler diskteki veriye, pdflush daemon tarafından, yansıtılmak (senkronize edilmek) zorundadır. Bellek sıkıntısı olduğunda buradaki veriler kswapd (ve pdflush) ile diske yazılarak yer açılabilir.
Anonymous Pages: Bu tip bellek alanları bir sürece ait değildir ve diskteki bir dosya ile senkronize edilmezler. Bellek sıkıntısı olduğunda buradaki veriler (kswapd ile) takas bölümüne yazılır.
İlk önce bulduğum araç iostat idi. Kullanabilmek için Ubuntu ve Fedora'da sysstat paketini kurmak gerekli.
Cyberciti'de güzelce açıklanmış. Örnek bir kullanım şöyle:
fd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 10.32 10.32 0.00
sda 0.01 5.92 0.07 4.98 2.88 87.32 17.87 0.69 137.16 1.48 0.75
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
fd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 1130.00 2.50 28.50 368.00 9268.00 310.84 0.23 7.42 1.77 5.50
iostat'ın parametrelerinden d disk kullanım verilerini, x ise ayrıtılı (eXtended) verileri göstermesini sağlıyor. Sonraki sayılardan ilki kaç saniye arayla tekrar verileri göstereceğini, sonraki ise kaç kez bu işlemi tekrarlayacağını gösteriyor. Ben 2 saniye arayla 2 kez istedim. Gösterilen verilere gelirsek
rrqm/s (Read ReQuests Merged per second): Sanyiede birleştirilmiş okuma istekleri (diskte sıraya alınmış)
wrqm/s (Write ReQuests Merged per second): Saniyede birleştirilmiş yazma istekleri (diskte sıralya alınmış)
r/s (Reads per second): Saniyedeki okuma istekleri
w/s (Writes per second): Saniyedeki yazma istekleri
rsec/s (Read Sectors per second): Saniyede okunan sektör sayısı
wsec/s (Write Sectors per second): Saniyede yazılan sektör sayısı
avgrq-sz (AVeraGe ReQuest sector SiZe ): Diske gelen tüm isteklerin sektör sayısı olarak ortalaması
avgqu-sz (AVeraGe ReQuest QUeue SiZe): Diske gelen tüm isteklerin kuyruk uzunluğu olarak ortalaması
await: Diske gelen tüm isteklerin ortalama (milisaniye) karşılanma süresi (kuyrukta bekleme + işlem)
svctm (SerViCe TiMe): Diske gelen tüm isteklerin ortalama işlem süresi (= await - queue time)
%util (bandwidth utilization): Diskin bant genlişliği kullanımı. %100'e yakın olması sınıra yaklaşılmış demek.
İkinci olarak iotop adındaki araç buldum.iotop varsayılan olarak etkileşimli olarak çalışan, sürekli olarak süreçlerin DISK READ ve DISK WRITE değerlerini görüntüleyen bir araç. Kullanabilmek için Ubuntu ve Fedora'da iotop paketini kurmak gerek. Örnek kullanım şöyle:
$ iotop -o
Total DISK READ: 93.45 K/s | Total DISK WRITE: 124.60 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2590 be/3 root 0.00 B/s 797.45 B/s ?unavailable? [kjournald]
4203 be/3 root 0.00 B/s 1594.90 B/s ?unavailable? [kjournald]
15645 be/2 root 0.00 B/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15649 be/2 root 0.00 B/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15652 be/4 root 0.00 B/s 353.56 K/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15656 be/2 root 0.00 B/s 450.12 K/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15661 be/2 root 17.13 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15662 be/2 root 2.34 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15663 be/2 root 6.23 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15664 be/2 root 58.41 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15666 be/2 root 9.35 K/s 1594.90 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15667 be/2 root 0.00 B/s 1594.90 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15668 be/4 root 0.00 B/s 276.46 K/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
Burada SWAPIN ve IO sütunlarının altında ?unavailable? yazmasının sebebini ekranın altındaki
hatasıyla açıklamış. Buna göre kernel'i uygun config ile tekrar derlemek gerek. Etkileşimli çalışma kipinde sağ ve sol ok tuşlarını kullanarak verilerin hangi alana göre sıralanacağını seçebiliriz. Seçilen alanın yanında bir ">" işareti belirir. Komut satırında kullandığım -o anahtarı ise sadece I/O yapan süreç ve thread'leri göster demek.
Üçüncü olarak budluğu araç ise vmstat. Bunu kullanabilmek için de sysstat paketini kurmak gerekli. Ben en çok bunu sevdim. Komut satırından çalıştırırken sadece kaç saniyede bir güncel verileri görüntüleyeceğini seçmek gerekiyordu, 1 ile ben her saniye görüntülemesini belirttim. Durdurana kadar her saniye yeni bir satır ekleyerek verileri tekrar yazıyor:
r b swpd free buff cache si so bi bo in cs us sy id wa
0 1 27800 39548 14796 3500092 0 0 2720 0 145 1991 1 3 88 8
0 5 27800 36204 14828 3502532 0 0 2644 520 194 2258 0 3 65 32
0 5 27800 33804 14848 3504596 0 0 2116 4 348 1922 1 3 26 70
0 1 27800 30848 14892 3506260 0 0 1584 0 232 2508 1 3 71 25
0 1 27800 26772 14940 3509760 0 0 3396 0 279 2924 1 4 74 21
0 1 27800 23332 14992 3512740 0 0 3028 0 225 2501 0 4 74 22
0 3 27800 25696 14984 3508956 0 0 1816 816 239 2168 0 5 59 36
0 3 27800 25368 15004 3509372 0 0 332 1408 486 1123 0 1 40 59
0 3 27800 29500 13272 3506900 0 0 1352 344 338 2122 1 2 32 64
1 2 27800 27004 13284 3509260 0 0 2308 0 230 2060 1 3 53 42
0 3 27800 30180 13288 3509732 0 0 748 0 152 2104 0 9 66 25
0 2 27800 25196 13324 3511936 0 0 1888 0 853 2381 3 12 52 33
1 2 27800 23768 13336 3513756 0 0 1832 48 1285 2756 5 9 60 26
Yukarıda görülen alanların anlamları (veri miktarı birimi KiB)
r (runtime): "Number of processes waiting for runtime". Çalışmak için bekleyen süreç sayısı diyelim. Ya süreç IO bekliyor, ya da CPU meşgul, bu sebeple bazı süreçler henüz görevlerini tamamlayamamış.
b (blocked): IO kaynağı eksikliği sebebiyle hizmet verilemeyen thread sayısı (başka bir kaynakta ise bekleme sebebinin IO olmayabileceği yazıyordu).
swpd: Kullanılan sanal bellek miktarı
free: Kullanılmayan bellek miktari
buff: Yazma işlemleri için ayrılan tampon bellek miktarı (RAM)
cache: Okuma işlemleri için ayrılan tampon bellek miktarı (RAM)
si (swap-in): Swap'ten okunan bellek miktarı
so (swap-out): Swap'e yazılan bellek miktarı
bi (block-in): Diskten okunan blok miktarı
bo (block-out): Diske yazılan blok miktarı
in: Saniyede gelen kesme (interrupt) sayısı (saat dahil)
cs: Saniyede yapılan context switching sayısı
Toplam CPU zamanını (% olarak) şöyle açıklayabiliriz:
%CPU zamanı = %Kullanıcı_süreçleri + %Kernel_süreçleri + %Boşta_zaman + %WIO
Buna göre (tümü yüzde olarak):
us: Kullanıcı süreçlerinin işletilmesine harcanan CPU zamanı
sy: Kernel (çekirdek) süreçlerini işletmek için harcanan CPU zamanı
id: Idle. CPU'nun boşta durma zamanı
wa: WIO, ya da wait-IO. CPU zamanın IO işlemlerini beklemek için harcanan kısmı
Artık şöyle yazabiliriz:
%CPU zamanı=us + sy + id + wa
vmstat ile ilgili güzel bir açıklama şu adreste var.
2019-08-28 Ek: vmstat sonuçlarının grafiğinin çizilmesi ile ilgili güzel bir proje buldum. git clone ile önce bir klasöre kopyaladım. vmstat değerlerini dosyaya yazabilmek için önce ekranda gördüğümüz sonuçları bir dosyaya yazmak lazım. En basit haliyle
Referanslar:
[1] www.ufsdump.org/papers/io-tuning.pdf
Biraz önbilgi. Linux çekirdeği disk IO'yu sayfalara böler. Birçok sistemde varsayılan sayfa boyutu 4K dır ($ getconf PAGESIZE komutu ile çalışan sistemin Page Size boyutunu görebilirsiniz). Linux, fiziksel adres alanı ile eşleştirilen bir "sanal bellek alanı" katmanı kullanır. Bir uygulamanın ihtiyaç duyduğu veri önce CPU cache'inde, daha sonra fiziksel bellekte aranır. Bulunamazsa bir majör sayfa hatası (MPF) oluşur ve aranan veri diskten okunarak RAM'deki tampon belleğe yazılır. Tampon bellekteki verilere erişim çağrıları minör sayfa hatasına (MnPF) sebep olur. MPF'ları azaltıp MnPF'ları artırmak için disk erişimlerinde buffer (yazma işlemleri için ayrılan tampon bellek) ve cache (okuma işlemleri için ayrılan tampon bellek) kullanılır. Bir sistemdeki toplam bellek miktarı, kullanılan bellek, buffer ve cache değerlerini
Komutu ile öğrenebiliriz.#cat /proc/meminfo
Bir sistemde üç tip bellek sayfası vardır:
Read Pages: MPF ile diskten okunan sayfalar. Bellekte read-only olarak tutulur. Kütüphane dosyaları gibi hiç değişmeyecek dosyaların ait verileri içerirler. Çekirdek ihtiyaç duydukça bunları kullanır. Bellek sıkıntısı olması durumunda bir kısmı boş olarak işaretlenir, uygulamalar buradaki verilere tekrar ihtiyaç duyduğunda MPF'lerle onları tekrar belleğe getirir.
Dirty Pages: Bu alandaki veriler çekirdek tarafından değiştirilen verilerdir. Değişiklikler diskteki veriye, pdflush daemon tarafından, yansıtılmak (senkronize edilmek) zorundadır. Bellek sıkıntısı olduğunda buradaki veriler kswapd (ve pdflush) ile diske yazılarak yer açılabilir.
Anonymous Pages: Bu tip bellek alanları bir sürece ait değildir ve diskteki bir dosya ile senkronize edilmezler. Bellek sıkıntısı olduğunda buradaki veriler (kswapd ile) takas bölümüne yazılır.
İlk önce bulduğum araç iostat idi. Kullanabilmek için Ubuntu ve Fedora'da sysstat paketini kurmak gerekli.
Cyberciti'de güzelce açıklanmış. Örnek bir kullanım şöyle:
$ iostat -d -x 2 2
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilfd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 10.32 10.32 0.00
sda 0.01 5.92 0.07 4.98 2.88 87.32 17.87 0.69 137.16 1.48 0.75
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
fd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 1130.00 2.50 28.50 368.00 9268.00 310.84 0.23 7.42 1.77 5.50
iostat'ın parametrelerinden d disk kullanım verilerini, x ise ayrıtılı (eXtended) verileri göstermesini sağlıyor. Sonraki sayılardan ilki kaç saniye arayla tekrar verileri göstereceğini, sonraki ise kaç kez bu işlemi tekrarlayacağını gösteriyor. Ben 2 saniye arayla 2 kez istedim. Gösterilen verilere gelirsek
rrqm/s (Read ReQuests Merged per second): Sanyiede birleştirilmiş okuma istekleri (diskte sıraya alınmış)
wrqm/s (Write ReQuests Merged per second): Saniyede birleştirilmiş yazma istekleri (diskte sıralya alınmış)
r/s (Reads per second): Saniyedeki okuma istekleri
w/s (Writes per second): Saniyedeki yazma istekleri
rsec/s (Read Sectors per second): Saniyede okunan sektör sayısı
wsec/s (Write Sectors per second): Saniyede yazılan sektör sayısı
avgrq-sz (AVeraGe ReQuest sector SiZe ): Diske gelen tüm isteklerin sektör sayısı olarak ortalaması
avgqu-sz (AVeraGe ReQuest QUeue SiZe): Diske gelen tüm isteklerin kuyruk uzunluğu olarak ortalaması
await: Diske gelen tüm isteklerin ortalama (milisaniye) karşılanma süresi (kuyrukta bekleme + işlem)
svctm (SerViCe TiMe): Diske gelen tüm isteklerin ortalama işlem süresi (= await - queue time)
%util (bandwidth utilization): Diskin bant genlişliği kullanımı. %100'e yakın olması sınıra yaklaşılmış demek.
İkinci olarak iotop adındaki araç buldum.iotop varsayılan olarak etkileşimli olarak çalışan, sürekli olarak süreçlerin DISK READ ve DISK WRITE değerlerini görüntüleyen bir araç. Kullanabilmek için Ubuntu ve Fedora'da iotop paketini kurmak gerek. Örnek kullanım şöyle:
$ iotop -o
Total DISK READ: 93.45 K/s | Total DISK WRITE: 124.60 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2590 be/3 root 0.00 B/s 797.45 B/s ?unavailable? [kjournald]
4203 be/3 root 0.00 B/s 1594.90 B/s ?unavailable? [kjournald]
15645 be/2 root 0.00 B/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15649 be/2 root 0.00 B/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15652 be/4 root 0.00 B/s 353.56 K/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15656 be/2 root 0.00 B/s 450.12 K/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15661 be/2 root 17.13 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15662 be/2 root 2.34 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15663 be/2 root 6.23 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15664 be/2 root 58.41 K/s 797.45 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15666 be/2 root 9.35 K/s 1594.90 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15667 be/2 root 0.00 B/s 1594.90 B/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
15668 be/4 root 0.00 B/s 276.46 K/s ?unavailable? vmware-vmx -C /vmacs/TESTM~ndard x64 Edition.vmx -@ ""
Burada SWAPIN ve IO sütunlarının altında ?unavailable? yazmasının sebebini ekranın altındaki
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %
hatasıyla açıklamış. Buna göre kernel'i uygun config ile tekrar derlemek gerek. Etkileşimli çalışma kipinde sağ ve sol ok tuşlarını kullanarak verilerin hangi alana göre sıralanacağını seçebiliriz. Seçilen alanın yanında bir ">" işareti belirir. Komut satırında kullandığım -o anahtarı ise sadece I/O yapan süreç ve thread'leri göster demek.
Üçüncü olarak budluğu araç ise vmstat. Bunu kullanabilmek için de sysstat paketini kurmak gerekli. Ben en çok bunu sevdim. Komut satırından çalıştırırken sadece kaç saniyede bir güncel verileri görüntüleyeceğini seçmek gerekiyordu, 1 ile ben her saniye görüntülemesini belirttim. Durdurana kadar her saniye yeni bir satır ekleyerek verileri tekrar yazıyor:
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----r b swpd free buff cache si so bi bo in cs us sy id wa
0 1 27800 39548 14796 3500092 0 0 2720 0 145 1991 1 3 88 8
0 5 27800 36204 14828 3502532 0 0 2644 520 194 2258 0 3 65 32
0 5 27800 33804 14848 3504596 0 0 2116 4 348 1922 1 3 26 70
0 1 27800 30848 14892 3506260 0 0 1584 0 232 2508 1 3 71 25
0 1 27800 26772 14940 3509760 0 0 3396 0 279 2924 1 4 74 21
0 1 27800 23332 14992 3512740 0 0 3028 0 225 2501 0 4 74 22
0 3 27800 25696 14984 3508956 0 0 1816 816 239 2168 0 5 59 36
0 3 27800 25368 15004 3509372 0 0 332 1408 486 1123 0 1 40 59
0 3 27800 29500 13272 3506900 0 0 1352 344 338 2122 1 2 32 64
1 2 27800 27004 13284 3509260 0 0 2308 0 230 2060 1 3 53 42
0 3 27800 30180 13288 3509732 0 0 748 0 152 2104 0 9 66 25
0 2 27800 25196 13324 3511936 0 0 1888 0 853 2381 3 12 52 33
1 2 27800 23768 13336 3513756 0 0 1832 48 1285 2756 5 9 60 26
Yukarıda görülen alanların anlamları (veri miktarı birimi KiB)
r (runtime): "Number of processes waiting for runtime". Çalışmak için bekleyen süreç sayısı diyelim. Ya süreç IO bekliyor, ya da CPU meşgul, bu sebeple bazı süreçler henüz görevlerini tamamlayamamış.
b (blocked): IO kaynağı eksikliği sebebiyle hizmet verilemeyen thread sayısı (başka bir kaynakta ise bekleme sebebinin IO olmayabileceği yazıyordu).
swpd: Kullanılan sanal bellek miktarı
free: Kullanılmayan bellek miktari
buff: Yazma işlemleri için ayrılan tampon bellek miktarı (RAM)
cache: Okuma işlemleri için ayrılan tampon bellek miktarı (RAM)
si (swap-in): Swap'ten okunan bellek miktarı
so (swap-out): Swap'e yazılan bellek miktarı
bi (block-in): Diskten okunan blok miktarı
bo (block-out): Diske yazılan blok miktarı
in: Saniyede gelen kesme (interrupt) sayısı (saat dahil)
cs: Saniyede yapılan context switching sayısı
Toplam CPU zamanını (% olarak) şöyle açıklayabiliriz:
%CPU zamanı = %Kullanıcı_süreçleri + %Kernel_süreçleri + %Boşta_zaman + %WIO
Buna göre (tümü yüzde olarak):
us: Kullanıcı süreçlerinin işletilmesine harcanan CPU zamanı
sy: Kernel (çekirdek) süreçlerini işletmek için harcanan CPU zamanı
id: Idle. CPU'nun boşta durma zamanı
wa: WIO, ya da wait-IO. CPU zamanın IO işlemlerini beklemek için harcanan kısmı
Artık şöyle yazabiliriz:
%CPU zamanı=us + sy + id + wa
vmstat ile ilgili güzel bir açıklama şu adreste var.
2019-08-28 Ek: vmstat sonuçlarının grafiğinin çizilmesi ile ilgili güzel bir proje buldum. git clone ile önce bir klasöre kopyaladım. vmstat değerlerini dosyaya yazabilmek için önce ekranda gördüğümüz sonuçları bir dosyaya yazmak lazım. En basit haliyle
# vmstat 1 > vmstat.txtile ekrana basmadan doğrudan dosyaya, ya da hem ekrana hem dosyaya göndermek için
# vmstat 1 | tee vmstat.txtile verileri dosyada biriktirdikten sonra clone'ladığımız klasörün içindeki index.html dosyasını browser ile açıp, vmstat.txt dosyasını sürükleyerek browser penceresinin ortasındaki alana bırakmamız, ya da hiç yerele girmeden doğrudan http://jsargiot.github.io/vmstatly/ adresinden çalışmamız mümkün.
Referanslar:
[1] www.ufsdump.org/papers/io-tuning.pdf
Kaydol:
Kayıtlar (Atom)