Büyük dosyalar nasıl sıralanır?


35

Intel (R) Pentium (R) CPU G640 @ 2,80 GHz ve 8 GB RAM'e sahip bir PC'm var. Üzerinde EXT3 dosya sistemi olan Scientific Linux 6.5 kullanıyorum.

Bu kurulumda sort -u200 gigabaytlık bir dosyada yapabileceğim en hızlı yöntem nedir?

Dosyayı daha küçük dosyalara bölmeli miyim (8 GB'tan küçük), sort -uonları bir araya getirmeli, sonra tekrar farklı bir boyutta sort -u, vb. Yeniden bölmeli miyim? Veya sınırlı miktarda RAM'imle bu kadar büyük dosyaları işleyebilecek herhangi bir sıralama komut dosyası veya programı var mı?


6
Lütfen sorunuzu düzenleyin ve gönderdiğiniz komutu denediğinizde ne olacağını açıklayın. Disk alanınız bitiyor mu? Komut, üzerinde yeterli boş alan olduğu sürece çalışmalıdır /tmp.
terdon


1
Seçilen cevap temelde @ terdon ne diyor diyor ama aynı zamanda bu da bir göz atın - stackoverflow.com/a/13025731/2801913 . Bunun paralleliçin GNU'ya ihtiyacınız olacak, bence parallelbazı sistemlerde varsayılan olarak yüklenen moreutils yerine .
Graeme

1
Dosyayı Amazon S3'e yükleyebilir, daha sonra sıralamak için birkaç düğümle bir Elastik Harita Azaltma işini döndürebilirsiniz!
Alan Shutko

2
sort(1)uzayda biterse /tmp; öyleyse, geçici değişkenler için ortam değişkeniyle TMPDIRveya -T=<tmpdir>
işaretiyle

Yanıtlar:


45

GNU sort(çoğu Linux sisteminde varsayılan) bir --parallelseçeneğe sahiptir. Gönderen http://www.gnu.org/software/coreutils/manual/html_node/sort-invocation.html :

'--Parallel = n'

Paralel olarak çalışan sıra sayısını n olarak ayarlayın. Varsayılan olarak, n, kullanılabilir işlemci sayısına ayarlanır, ancak bundan sonra azalan performans kazancı olduğundan 8 ile sınırlıdır. Ayrıca, n thread kullanmanın hafıza kullanımını log n sayısının arttırdığını unutmayın. Ayrıca bakınız nproc çağrısı.

İşlemcinizde 2 çekirdek olduğundan, şunları yapabilirsiniz:

sort --parallel=2 -uo list-sorted.txt list.txt

Asıl çekirdek sayısını belirlemek daha iyidir, çünkü hiper iş parçacıklı işlemciye bağlı olarak daha fazla görünebilir .

niceİşlemci zamanlama önceliğini ioniceetkilemek ve G / Ç zamanlamasını etkilemek için de deneyebilirsiniz . Bunun gibi diğer işlemlere göre önceliği artırabilirsiniz, bunun bir arka plan işleminin çok fazla kaynak kullanmadığından emin olmak için genellikle daha iyi olduklarından bunun size büyük tasarruf sağlayacağını sanmıyorum . Asla-az, onları gibi bir şeyle birleştiremezsiniz:

nice -n -20 ionice -c2 -n7 sort --parallel=2 -uo list-sorted.txt list.txt

Ayrıca, Gilles'un yorumladığı gibi, tek bir GNU sort komutunu kullanmak, algoritma zaten büyük dosyaları işlemek için optimize edilmiş olduğundan, sıralama ayırmanın diğer yöntemlerinden daha hızlı olacağını unutmayın. Başka bir şey muhtemelen işleri yavaşlatacaktır.


10
Ve sortdirekt olarak aramanın , başarabileceğiniz her şeyden daha iyi olduğunu da not etmelisin . GNU sıralama RAM'den daha büyük dosyalarla iyi başa çıkmak için tasarlanmıştır.
Gilles 'SO- kötü olmayı'

--Parallel sort seçeneği RH6.5 sunucularımda çalışmıyor. Sort --version, coreutils 8.4'ten kaynaklandığını düşünüyor. Paralel sürüme hangi sürüme ihtiyacım var?
markus_b

3
Ayrıca bakınız superuser.com/questions/938558/sort-parallel-isnt-parallelizing - Eğer aslında paralel olmadığını fark ederseniz -S512M gibi bir şey belirtmeniz gerekebilir.
saat

46

sortKomutu kullanmak muhtemelen en hızlı seçenek olacaktır.

Ancak muhtemelen yerel ayarı C’ye sabitlemek isteyeceksiniz.

sort -ubenzersiz satırlar bildirmez, ancak aynı sıralama yapan her satır kümesinden biri. C yerel ayarında, 2 farklı satır mutlaka aynı şekilde sıralanmaz, ancak GNU sistemlerindeki çoğu UTF-8 tabanlı yerel durum için durum böyle değildir.

Ayrıca, C yerel ayarını kullanmak, UTF-8'i ayrıştırmaktan ve genel sıralama düzenleri işlemek zorunda kalmamaktan ötürü performansı önemli ölçüde artıracaktır.

Yani:

LC_ALL=C sort -u file

Ayrıca geçici dosyalar için daha hızlı bir sürücü (veya giriş ve / veya çıkış dosyalarının olduğu sürücüden farklı bir sürücü) kullanarak ( -Tveya veya $TMPDIRortam değişkenini kullanarak ) veya -Sbazı sortuygulamaların desteklediği seçeneğe bağlı kalarak performansı artırabilirsiniz. .

Bir tür girdi veya yavaş depolama için, --compress-programGNU seçeneğini sort(örneğin ile lzop) kullanmak, depolama kullanımına ek olarak performansı da artırabilir.


Şimdi sadece itiraz edenler için (bir dereceye kadar) bunun doğru düzen olmayacağına dair bir not :

Bir insan olarak Stefan ve Stephanie arasında Stéphane'yi görmek isterdim , ama:

  • Bir bilgisayar , Stéphane'nin o tarihten sonra é(en azından U + 00E9 olarak ifade edildiğinde) bir karakter olarak veya UTF-8 kodlama türlerinin baytını (kod noktası veya bayt değeri cinsinden) bir karakter olarak sıralamasını ister. Bu, uygulanması çok kolay olan ve katı bir toplam sipariş olan ve hiç sürpriz yapmayan bir sıralama düzenidir .
  • Yerel ayarların sıralama düzeni muhtemelen birçok insanda bile tatmin edici olmayacaktır. Örneğin, varsayılan en_GB.utf8 yerel ayarına sahip sistemimde:

    • Stéphane ve Stéphane (biri U + 00E9, diğeri eU + 0301 ile) aynı şekilde sıralamaz:

      $ printf '%b\n' 'Ste\u0301phane' 'St\u00e9phane' | sort -u
      Stéphane
      Stéphane
      
    • fakat ③, ①, ② hepsi aynı şekilde sıralar (bu yerel ayarlarda bir hata)

      $ printf '%s\n' ③ ① ② | sort -u
      ③
      

      Burada, ③, ama ① veya ② olabilirdi.

Yani IMO, sort -ubenzersiz çizgiler istiyorsanız , şansınız her zaman LC_ALL = C olsun. Bu sonuç listesinin kullanıcının sıralama düzeninde sıralanmasını istiyorsanız, sorttekrar sıralayın :

LC_ALL=C sort -u | sort

LC_ALL=C sort | LC_ALL=C uniq -c | sort -k2

8
Yerel ayarları belirlemek için +1: performans üzerinde çok büyük bir etkisi olabilir
Adrian Pronk

1
Evet. 250000 satırlı dosya sıralama LC_ALL işleri 8 kat hızlandırır.
Jan Vlcinsky

-1

İşte GB ram çift ile düzenli makinede TB ölçek verileri sıralamak için bash komut dosyasını kullanmak için hazır: http://sgolconda.blogspot.com/2015/11/sort-very-large-dataset.html Bu sayısını kontrol eder makinenizi çekirdek olarak kullanır ve tüm çekirdekleri kullanır. Dosyaları sıralayabilir, sayısal veya dizelleyebilir. TB ölçeği verilerinde benzersiz kayıtları bulmak için kullanılabilir.


Bu iyi bir öneri değil. Betik derece şişirilmiş ve giriş dosyasını, kabul edilen cevabın GNU sıralamalarında gerekli olmadığını gösterdiği kısımları sıralamak için böler.
Thorbjørn Ravn Andersen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.