Birçok geliştirici bir ortama bağımlıdır. Linux için Windows Alt Sistemi Linux araçları Windows içinde sorunsuz çalışabilir, ancak projeler doğrudan Windows disklerinden çalıştırıldığında bu ortamın performansı önemli ölçüde düşebilir. Bu durum genellikle yavaş komut yürütme, gecikmeli dosya yükleme veya büyük projeler işlenirken düşük yanıt verme hızı şeklinde kendini gösterir.
Bu performans düşüşü, WSL2'nin dosya sistemini nasıl ele aldığıyla ilgilidir; Windows dosyalarına, okuma ve yazma hızlarını etkileyen bir ara katman üzerinden erişilir. Dosya veya işlem sayısı ne kadar fazla olursa, etki o kadar büyük olur ve bu da geliştirme ortamını, yerel bir Linux sisteminde veya WSL2 dosya sisteminin kendisinde çalışmaya kıyasla daha az verimli hale getirir.
Neyse ki, projeleri WSL2 dahili dosya sistemine taşıyarak veya iş akışlarını bu ortama uyarlayarak performans önemli ölçüde iyileştirilebilir. Sorunun temel nedenini anlamak, daha iyi kararlar almanıza ve daha hızlı, daha istikrarlı bir geliştirme deneyimi elde etmenize yardımcı olur.
Windows için Linux Alt Sistemi'ni ilk kullanmaya başladığınızda her şey normal çalışıyor gibi görünür. Bir depoyu klonlayabilir, bağımlılıkları kurabilir, uygulamanızı çalıştırabilir ve hatta artık "Windows üzerinde Linux"a sahip olduğunuza kendinizi ikna edebilirsiniz.
Sonra bir şeylerin ters gittiğini hissedersiniz ve anında gerçekleşmesi gereken komutların önemli ölçüde zaman aldığını fark edersiniz. Paket kurulumları yavaşlar, dosya izleme sistemleri düzensiz davranır ve geliştirme sunucuları kolayca açıklanamayan şekillerde yavaş çalışır. Başlangıçta, bariz suçlu olarak WSL2'nin kendisi suçlanır, ancak genellikle yanlış suçludur.
Asıl sorun dosyalarınızın nerede bulunduğunda yatıyor.
Windows dosya sistemi, gizli bir performans düşüşüne neden olur.
Projeniz aşağıdaki gibi bir yerde bulunuyorsa:
/mnt/c/Users/YourName/projects/my-app
Aslında üzerinde çalışmadığınız bir konu bu. dosya sistemi Linux. Çeviri katmanı aracılığıyla erişilen Windows dosya sistemi üzerinde çalışıyorsunuz.
Bu ayrıntıyı gözden kaçırmak kolaydır ve şaşırtıcı derecede maliyetlidir. WSL2, hafif bir sanal makine içinde gerçek bir Linux çekirdeği çalıştırır. Bu ortamda, yerel bir Linux dosya sistemi bulunur. Hızlı, tutarlı ve Linux araçlarından beklediğiniz gibi davranır.
Ancak, aşağıdaki dosyalara eriştiğinizde /mnt/c، /mnt/dYüklü herhangi bir Windows sürücüsünde, her dosya işlemi Linux ve Windows arasında bir sınırdan geçmek zorundadır. Performansın düştüğü yer işte bu sınırdır (sessizce, hata mesajı göstermeden, ki bu da durumu daha da kötüleştirir).
Bu durum neden işleri yavaşlatıyor?
Dosya yoğunluğu yüksek iş yükleri, dosya sistemi çevirisinin maliyetini artırır.
Modern yazılım geliştirme iş yükleri büyük ölçüde dosya tabanlıdır. Şöyle bir şey çalıştırdığınızda neler olduğunu düşünün:
npm install
pip install
cargo build
npm run devBu araçlar binlerce küçük dosya oluşturur, okur ve değiştirir. Dosya sistemine hızlı erişime ve öngörülebilir davranışa dayanırlar.
Yerel Linux dosya sisteminde bu işlem optimize edilmiştir, ancak WSL2 üzerinden erişilen Windows dosya sisteminde bu işlemlerin her biri iki farklı sistem arasında çeviri gerektirir.
Sonuç olarak, işler yolunda gidiyor ama her şey daha yavaş. Bazen yarı yarıya yavaşlıyor, bazen 10 kat daha yavaş, bazı durumlarda ise daha da kötü olabiliyor. Yavaşlama birçok küçük sürece yayıldığı için bunu her zaman hemen fark etmiyorsunuz, ancak zamanla birikiyor.
Bu sorunu tespit etmenin en kolay yollarından biri Git kullanmaktır. `/mnt/c` altında depolanan büyük bir depoda `git status` veya `git checkout` komutunu çalıştırın ve bunu Linux ana dizininizdeki aynı depoyla karşılaştırın.
Aradaki fark çok belirgin; Git birçok dosya sistemi işlemi gerçekleştiriyor. Dizinleri tarıyor, meta verileri kontrol ediyor ve dosya durumlarını karşılaştırıyor. Yavaş bir dosya sistemi köprüsünde bu durum çok açık bir şekilde ortaya çıkıyor. İnsanlar genellikle Git'in kendisini suçluyor veya depolarının "çok büyük" olduğunu varsayıyor. Gerçekte, sorunların çoğuna neden olan şey dosya sistemi seçimidir.
Bir diğer yaygın sorun ise güvenilmeyen dosyaların izlenmesidir. Webpack, Vite veya Nodemon gibi araçlar, değişiklikleri tespit etmek için dosya sistemi olaylarına güvenir. Yerel bir Linux dosya sisteminde, bu olaylar verimli bir şekilde işlenir.
Windows'un sınırlarının ötesinde, işler tutarsız hale geliyor.
Şunları fark edebilirsiniz:
- Değişiklikler yeniden inşaya yol açmaz.
- gecikmeli yeniden yükleme
- Yedekleme algılama mekanizmaları nedeniyle artan CPU kullanımı
Bu, kullandığınız araçlarla ilgili bir sorun değil; Windows ve Linux arasında dosya sistemi bildirimlerinin nasıl çevrildiğinden kaynaklanıyor. Projeyi WSL2 dosya sistemine taşımak bu sorunları çözmelidir.
/mnt/c'nin yanıltıcı rahatlığı
Kolaylık, sistemlere erişimin maliyetini gizler.
İnsanların buraya gelmesinin nedenini anlamak gayet doğal. Windows'ta çalışmaya başlıyorsunuz ve dosyalarınız ve editörünüz orada. Bunlara WSL2 üzerinden erişmek doğal görünüyor. /mnt/c.
Bu size birleşik bir ortam yanılsaması verir. Hem Windows'tan hem de Linux'tan erişilebilen tek bir dosya sistemi, ancak bu birleşik değil, bir köprüdür ve köprülerin de maliyetleri vardır.
Bu yapılandırma, dosyalara ara sıra erişim için uygundur, ancak yüksek frekanslı dosya sistemi işlemlerine dayanan aktif geliştirme iş yükleri için uygun değildir.
WSL2 içinde Linux dosya sistemiyle çalışırken fark hemen ortaya çıkar. Yolunuz şu şekilde görünür:
Artık tamamen Linux ortamında çalışıyorsunuz, çeviri katmanı veya çapraz işletim sistemi yükü yok. Bu kılavuzda, bağımlılıkları yüklemeye çalışırsanız, bunların çok daha hızlı tamamlandığını ve geliştirme sunucularının daha hızlı başlatıldığını ve daha güvenilir bir şekilde yeniden yüklendiğini fark edeceksiniz.
Peki ya Windows'tan erişim?
Modern editörler zaten uzaktan Linux iş akışlarını destekliyor.
İşte bu kısım insanları tereddüte düşürüyor. Projeniz WSL2 içinde yer alıyorsa, onu Windows düzenleyicinizde nasıl açacaksınız?
Cevap şu ki, modern araçlar bu sorunu zaten çözmüş durumda. Eğer VS Code kullanıyorsanız, Uzaktan WSL uzantısı Bu, Linux dosya sisteminizi doğrudan açmanıza olanak tanır. VS Code Windows'ta çalışır, ancak dosyalar WSL2 içinde kalır.
Bu, amaçlanan iş akışıdır. Geliştirme deneyiminizi korurken (tamamen olmasa da) performans kayıplarını önler. WSL dosyalarına aşağıdaki yoldan da erişebilirsiniz:
\wsl$YourDistrohomeyouruserprojects
Ancak aktif geliştirme için uzaktan entegrasyon yaklaşımı daha temizdir.
/mnt/c komutunu ne zaman kullanmaya devam edebilirsiniz?
Bazı iş yükleri hala Windows dosya sisteminden faydalanmaktadır.
Dürüst olmak gerekirse, Windows dosya sistemi bu bağlamda işe yaramaz değil. Belgelere veya medya dosyalarına erişim, ortamlar arasında basit komut dosyalarının paylaşımı ve yalnızca Windows'a özgü araçlarla birlikte çalışabilirlik gibi geçerli kullanım durumları mevcut. Ancak, özellikle büyük bağımlılık ağaçları veya tekrarlayan dosya işlemleri içeren aktif geliştirme için, projenizi yerleştirmek için yanlış bir yer. WSL2'yi "Windows içinde Linux" olarak değil, Windows ile iyi entegre olan ayrı bir Linux sistemi olarak düşünmek faydalı olacaktır.
Bu modeli benimsediğinizde, dosya sistemi kararı netleşir. Tipik olarak, yüksek gecikme süresine sahip ağ tabanlı bir dosya sisteminde Linux projesi geliştirmezsiniz. Yerel ortamda tutarsınız. WSL2'de Linux dosya sistemi yerel ortamınızdır ve Windows dosya sistemi Linux açısından neredeyse uzak bir konumdadır.
Sorunu çözmek birkaç dakika sürüyor.
Projeyi Linux dosya sistemi içinde aktarın veya kopyalayın.
Çözüm karmaşık değil. Tek yapmanız gereken projenizi taşımak:
mv /mnt/c/Users/YourName/projects/my-app ~/projects/ Veya doğrudan WSL2 içinde kopyalayın:
git clone <repo> ~/projects/my-app Yeni siteyi açmak için kod düzenleyicinizi güncelleyin.
Performans, ayarlardan çok konuma bağlıdır.
WSL2, iç sınırlarına saygı gösterilerek, eksiksiz bir Linux ortamı olarak ele alındığında en iyi şekilde çalışır. Bir proje bu çerçeve içinde yaşamaya başladığında, hibrit iş akışlarıyla ilişkili sürtüşmelerin çoğu ortadan kalkar. Windows bir arayüz katmanı olarak kullanışlı olmaya devam eder, ancak uygulama bağlamı tekrar tutarlı hale gelir ve araçlar tasarlandıkları gibi davranır.
İlginç olan, bu duruma ulaşmak için ne kadar az çaba gerektiğidir. Konumu değiştirmek, çoğu Ayarlar değişikliğinden daha fazla performans değişikliği sağlar. Bu sezgisel hale geldiğinde, önceki davranış daha az gizemli ve sürekli ileri geri erişim için optimize edilmemiş sistemlerde gezinmenin beklenen bir sonucu gibi görünmeye başlar.
