2TBのRAMを持つシステムがあり、バッファサイズを1000Gと指定する150Gサイズのファイルに対してソートコマンドを実行しています。 Googleで調査した後、「バッファ領域のサイズが大きいほど、パフォーマンスが良いほど」。これが私が実行したコマンドです
sort -rk2 --buffer-size=1000G master_matrix_unsorted.csv > master_matrix_sorted.csv
ところで、時間がかかり、作業がどのように進んでいるのか分かりません。
これに最適なバッファサイズがどれくらいかわかりますか？新しいバッファサイズでこのタスクを再実行する予定です。
ベストアンサー1
オペレーティングシステムとソート実装を指定する必要はありません。 GNUソートを意味するようです。また、「多くの時間」がどれくらいかかるのか、どれくらいの時間がかかると予想しているのかは言及していない。最も重要なことは、決定要因となるI / Oサブシステムの機能について言及していないことです。
一般的なSATAドライブの転送速度は約150MB / sです。この速度では、150GBのファイルを読み取るのに1000秒（約15分）かかります。それを試して$ time cat filename >/dev/nullみてください。約15分（またはtime cat表示された時間）が問題ない場合は、出力も作成する必要があるため、その時間の約3倍以内にsort（1）が機能するようにすることができます。
データがメモリに適しており、余分なプロセッサがあるため、速度を向上させるための最良のオプションは並列処理のようです。情報ページによると、--buffer-sizeは問題ではありません。
... このオプションは初期バッファサイズにのみ影響します。 「ソート」でSIZEより大きい入力行が見つかると、バッファはSIZEを超えます。
そして、クイック検索でGNUが使用していることがわかります。マージソート、これは並列化に適しています。
GNUソートがバッファサイズを決定する方法と並列ソートに使用するアルゴリズムを本当に知りたい場合は、いつでもcoreutilsソースコードに付属のドキュメントを入手できます。
しかし、私があなたなら迷惑にならないでしょう。何を使用しても、master_matrix_unsorted.csvsort(1) は確かに作業には適していません。
まず、いつかCSV構文がソートの理解をはるかに超えているので、CSVファイルを使用すると間違いを犯すでしょう。 2番目に、sort（1）は、2番目の列だけでなく（長さが不確実な）行全体をソートする必要があるため、最も遅い方法です。第三に、仕事を終えると何が得られますか？ ㅏソート済みCSVファイル。これは本当に良いことでしょうか？なぜ注文するそれはとても重要ですか？
ソートは、その目標に向かって一段階のように聞こえ、必要なデータの一種の計算を含むことができる。数字バイナリ形式で。この場合、CSVファイルをより管理しやすく、計算可能な形式に変換できます。バイナリまず、DBMSでフォーマットを実行します。最終目標の優先順位を決めることは不要であることがわかります。