Python読み取りパフォーマンスの問題

Question

以前のスレッドに続いて、PerlスクリプトからPythonスクリプトに移行する際に問題を骨抜きにしたので、Pythonでファイルを丸呑みするときに大きなパフォーマンスの問題が見つかりました。これをUbuntuサーバーで実行します。

注意：これはX対Yのスレッドではありません。これがどのようなものなのか、あるいは私が愚かなことをしているのかどうかを根本的に知る必要があります。

テストデータとして50,000個の10kbファイルを作成しました（これは、処理しているものの平均ファイルサイズを反映しています）。

mkdir 1
cd 1
for i in {1..50000}; do dd if=/dev/zero of=$i.xml bs=1 count=10000; done
cd ..
cp -r 1 2

できるだけ簡単に2つのスクリプトを作成しました。

Perl

foreach my $file (<$ARGV[0]/*.xml>){
    my $fh;
    open($fh, "< $file");
    my $contents = do { local $/; <$fh> };
    close($fh);
}

Python

import glob, sys
for file in glob.iglob(sys.argv[1] + '/*.xml'):
    with open(file) as x:
        f = x.read()

次に、キャッシュをクリアして2つのSlurpスクリプトを実行しました。実行するたびに、次のコマンドを使用してキャッシュを再度クリーンアップしました。

sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

次に、毎回ディスクからすべてを読み取っていることを確認するために監視されました。

Sudo iotop -a -u me

RAID 10ディスクを備えた物理マシンと、VMがRAID 1 SSDにある新しいVMセットアップでこれを試しました。VMからのテスト実行が含まれています。物理サーバーはほとんど同じで、高速でした。

$ time python readFiles.py 1
    real    5m2.493s
    user    0m1.783s
    sys     0m5.013s

$ time Perl readFiles.pl 2
    real    0m13.059s
    user    0m1.690s
    sys     0m2.471s

$ time Perl readFiles.pl 2
    real    0m13.313s
    user    0m1.670s
    sys     0m2.579s

$ time python readFiles.py 1
    real    4m43.378s
    user    0m1.772s
    sys     0m4.731s

PerlがDISK READを実行しているときのiotopで、Python DISK READが2M/sでIOWAIT 97％の場合、約45 M/s、IOWAITが約70％であることに気付きました。私がそれらを煮詰めてできる限り単純なものにしたので、ここからどこへ行くべきかわかりません。

関連する場合

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2

$ Perl -v
This is Perl 5, version 18, Subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi

必要に応じて詳細情報

私はstraceを実行してファイル1000.xmlの情報を取得しましたが、すべて同じことをしているようです：

Perl

$strace -f -T -o trace.Perl.1 Perl readFiles.pl 2

32303 open("2/1000.xml", O_RDONLY)      = 3 <0.000020>
32303 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7f6f7b90) = -1 ENOTTY (Inappropriate ioctl for device) <0.000016>
32303 lseek(3, 0, SEEK_CUR)             = 0 <0.000016>
32303 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000016>
32303 fcntl(3, F_SETFD, FD_CLOEXEC)     = 0 <0.000017>
32303 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000030>
32303 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.005323>
32303 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 1808 <0.000022>
32303 read(3, "", 8192)                 = 0 <0.000019>
32303 close(3)                          = 0 <0.000017>

Python

$strace -f -T -o trace.python.1 python readFiles.py 1

32313 open("1/1000.xml", O_RDONLY)      = 3 <0.000021>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000017>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000019>
32313 lseek(3, 0, SEEK_CUR)             = 0 <0.000018>
32313 fstat(3, {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000018>
32313 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa18820a000 <0.000019>
32313 lseek(3, 0, SEEK_CUR)             = 0 <0.000018>
32313 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 <0.006795>
32313 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 1808 <0.000031>
32313 read(3, "", 4096)                 = 0 <0.000018>
32313 close(3)                          = 0 <0.000027>
32313 munmap(0x7fa18820a000, 4096)      = 0 <0.000022>

私が気付いた1つの違いは、関連があるかどうかは不明ですが、Perlがすべてのファイルに対してこれを実行するように見えますが、pythonはそうではありません。

32303 lstat("2/1000.xml", {st_mode=S_IFREG|0664, st_size=10000, ...}) = 0 <0.000022>

また、-cを使用してstraceを実行しました（上位の呼び出しをいくつか受けただけです）。

Perl

$ time strace -f -c Perl readFiles.pl 2
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 44.07    3.501471          23    150018           read
 12.54    0.996490          10    100011           fstat
  9.47    0.752552          15     50000           lstat
  7.99    0.634904          13     50016           open
  6.89    0.547016          11     50017           close
  6.19    0.491944          10     50008     50005 ioctl
  6.12    0.486208          10     50014         3 lseek
  6.10    0.484374          10     50001           fcntl

real    0m37.829s
user    0m6.373s
sys     0m25.042s

Python

$ time strace -f -c python readFiles.py 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.97    4.186173          28    150104           read
 15.58    1.518304          10    150103           fstat
 10.51    1.023681          20     50242       174 open
 10.12    0.986350          10    100003           lseek
  7.69    0.749387          15     50047           munmap
  6.85    0.667576          13     50071           close
  5.90    0.574888          11     50073           mmap

real    5m5.237s
user    0m7.278s
sys     0m30.736s

-Tをオンにしてstrace出力を解析し、各ファイルの最初の8192バイトの読み取りをカウントしました。これが時間が経過していることは明らかです。以下は、ファイルの50000回の最初の読み取りに費やされた合計時間とそれに続く各読み取りの平均時間。

300.247128000002 (0.00600446220302379)   - Python
11.6845620000003 (0.000233681892724297)  - Perl

それが役立つかどうかわかりません！

PDATE 2 os.openとos.readを使用するようにPythonのコードを更新し、最初の4096バイトの単一の読み取りを実行します（必要な情報が上部にあるため、私にとってはうまくいきます）ファイルの）、strace内の他のすべての呼び出しも排除します：

18346 open("1/1000.xml", O_RDONLY)      = 3 <0.000026>
18346 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 <0.007206>
18346 close(3)                          = 0 <0.000024>

$ time strace -f -c python readFiles.py 1
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 55.39    2.388932          48     50104           read
 22.86    0.986096          20     50242       174 open
 20.72    0.893579          18     50071           close

real    4m48.751s
user    0m3.078s
sys     0m12.360s

Total Time (avg read call)
282.28626 (0.00564290374812595)

まだ良くありません...次に、AzureでVMを作成して、別の例を試してみます。

PDATE 3-このサイズの謝罪!!

3つのセットアップで（@ J.F.Sebastian）スクリプトを使用して興味深い結果をいくつかわかりました。簡潔にするために、最初に出力を取り除き、キャッシュから超高速で実行されるすべてのテストを削除しました。

0.23user 0.26system 0:00.50elapsed 99%CPU (0avgtext+0avgdata 9140maxresident)k
0inputs+0outputs (0major+2479minor)pagefaults 0swaps

Azure A2標準VM（2コア3.5GB RAMディスクが不明ですが遅い）

$ uname -a
Linux servername 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
$ Perl -v
This is Perl 5, version 18, Subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see Perl -V for more detail)

+ /usr/bin/time Perl Slurp.pl 1
1.81user 2.95system 3:11.28elapsed 2%CPU (0avgtext+0avgdata 9144maxresident)k
1233840inputs+0outputs (20major+2461minor)pagefaults 0swaps
+ clearcache
+ sync
+ Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python Slurp.py 1
1.56user 3.76system 3:06.05elapsed 2%CPU (0avgtext+0avgdata 8024maxresident)k
1232232inputs+0outputs (14major+52273minor)pagefaults 0swaps
+ /usr/bin/time Perl Slurp.pl 2
1.90user 3.11system 6:02.17elapsed 1%CPU (0avgtext+0avgdata 9144maxresident)k
1233776inputs+0outputs (16major+2465minor)pagefaults 0swaps

両方の比較可能な最初のスラープ結果、2番目のPerlスラープ中に何が起こっていたのかわかりませんか？

My VMWare Linux VM（2コア8GB RAMディスクRAID1 SSD）

$ uname -a
Linux servername 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
$ Perl -v
This is Perl 5, version 18, Subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
(with 41 registered patches, see Perl -V for more detail)

+ /usr/bin/time Perl Slurp.pl 1
1.66user 2.55system 0:13.28elapsed 31%CPU (0avgtext+0avgdata 9136maxresident)k
1233152inputs+0outputs (20major+2460minor)pagefaults 0swaps
+ clearcache
+ sync
+ Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python Slurp.py 1
2.10user 4.67system 4:45.65elapsed 2%CPU (0avgtext+0avgdata 8012maxresident)k
1232056inputs+0outputs (14major+52269minor)pagefaults 0swaps
+ /usr/bin/time Perl Slurp.pl 2
2.13user 4.11system 5:01.40elapsed 2%CPU (0avgtext+0avgdata 9140maxresident)k
1233264inputs+0outputs (16major+2463minor)pagefaults 0swaps

今回は、以前と同様に、Perlは最初のSlurpの方がはるかに高速です。2番目のPerl Slurpで何が起こっているかはわかりませんが、この動作は以前には見られませんでした。 measure.shを再度実行したところ、結果はまったく同じでしたか、数秒かかりました。次に、通常の人が行うことと同じことを行い、Azureマシン3.13.0-35-genericに一致するようにカーネルを更新して、再びmeasure.shを実行しましたが、結果に違いはありませんでした。

好奇心から、それから、measure.shの1と2のパラメーターを入れ替えると、何か奇妙なことが起こりました。Perlが遅くなり、Pythonが高速になりました！

+ /usr/bin/time Perl Slurp.pl 2
1.78user 3.46system 4:43.90elapsed 1%CPU (0avgtext+0avgdata 9140maxresident)k
1234952inputs+0outputs (21major+2458minor)pagefaults 0swaps
+ clearcache
+ sync
+ Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python Slurp.py 2
1.19user 3.09system 0:10.67elapsed 40%CPU (0avgtext+0avgdata 8012maxresident)k
1233632inputs+0outputs (14major+52269minor)pagefaults 0swaps
+ /usr/bin/time Perl Slurp.pl 1
1.36user 2.32system 0:13.40elapsed 27%CPU (0avgtext+0avgdata 9136maxresident)k
1232032inputs+0outputs (17major+2465minor)pagefaults 0swaps

これは私をさらに混乱させました:

---（物理サーバー（32コア132 GB RAMディスクRAID10 SAS）

$ uname -a
Linux servername 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ python
Python 2.7.3 (default, Aug  1 2012, 05:14:39)
[GCC 4.6.3] on linux2
$ Perl -v
This is Perl 5, version 14, Subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
(with 55 registered patches, see Perl -V for more detail)

+ /usr/bin/time Perl Slurp.pl 1
2.22user 2.60system 0:15.78elapsed 30%CPU (0avgtext+0avgdata 43728maxresident)k
1233264inputs+0outputs (15major+2984minor)pagefaults 0swaps
+ clearcache
+ sync
+ Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+ /usr/bin/time python Slurp.py 1
2.51user 4.79system 1:58.53elapsed 6%CPU (0avgtext+0avgdata 34256maxresident)k
1234752inputs+0outputs (16major+52385minor)pagefaults 0swaps
+ /usr/bin/time Perl Slurp.pl 2
2.17user 2.95system 0:06.96elapsed 73%CPU (0avgtext+0avgdata 43744maxresident)k
1232008inputs+0outputs (14major+2987minor)pagefaults 0swaps

ここではPerlが毎回勝つようです。

困惑

ローカルVMの奇妙さを考えると、私が最も制御できるマシンであるディレクトリをスワップしたとき、pythonとPerlを1または2として使用して実行するすべての可能なオプションでバイナリアプローチを試すつもりです。データディレクトリと一貫性を保つためにそれらを複数回実行してみますが、しばらく時間がかかり、少し頭がおかしいので、最初にブレークが必要になる場合があります。私が欲しいのは一貫性です:

---（更新4-整合性

（以下はubuntu-14.04.1-server VMで実行され、カーネルは3.13.0-35-generic＃62-Ubuntuです）

データのディレクトリ1/2でPython/Perl Slurpの可能な限りあらゆる方法でテストを実行して、私は次のことを発見しました：

• Pythonは、作成されたファイル（つまり、ddによって作成されたファイル）で常に遅い
• Pythonは常にコピーされたファイルで高速です（つまり、cp -rで作成されます）
• Perlは作成されたファイル（つまり、ddによって作成されたファイル）で常に高速です
• コピーされたファイル（つまり、cp -rによって作成されたファイル）ではPerlが常に遅い

だから私はOSレベルのコピーを見て、Ubuntuでは「cp」はPythonと同じように動作するようです、つまり元のファイルでは遅く、コピーされたファイルでは速く見えます。

これが私が実行したものであり、結果は、単一のSATA HDを搭載したマシンとRAID10システムで数回実行した結果です。

$ mkdir 1
$ cd 1
$ for i in {1..50000}; do dd if=/dev/urandom of=$i.xml bs=1K count=10; done
$ cd ..
$ cp -r 1 2
$ sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy2c cp -r 2 2copy
    real    0m28.624s
    user    0m1.429s
    sys     0m27.558s
$ sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy1c cp -r 1 1copy
    real    5m21.166s
    user    0m1.348s
    sys     0m30.717s

トレース結果は時間が費やされている場所を示します

$ head trace.copy1c trace.copy2c
==> trace.copy1c <==
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 60.09    2.541250          25    100008           read
 12.22    0.516799          10     50000           write
  9.62    0.406904           4    100009           open
  5.59    0.236274           2    100013           close
  4.80    0.203114           4     50004         1 lstat
  4.71    0.199211           2    100009           fstat
  2.19    0.092662           2     50000           fadvise64
  0.72    0.030418         608        50           getdents
==> trace.copy2c <==
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 47.86    0.802376           8    100008           read
 13.55    0.227108           5     50000           write
 13.02    0.218312           2    100009           open
  7.36    0.123364           1    100013           close
  6.83    0.114589           1    100009           fstat
  6.31    0.105742           2     50004         1 lstat
  3.38    0.056634           1     50000           fadvise64
  1.62    0.027191         544        50           getdents

だからコピーのコピーは元のファイルのコピーよりもはるかに速いようですが、私の現在の推測では、コピーされたファイルは最初に作成されたときよりもディスク上で整列され、読み取りがより効率的になりますか？

興味深いことに、「rsyn」と「cp」は、PerlとPythonのように、速度的に反対の方法で機能するようです。

$ rm -rf 1copy 2copy; sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Rsync 1"; /usr/bin/time rsync -a 1 1copy; sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Rsync 2"; /usr/bin/time rsync -a 2 2copy
Rsync 1
    3.62user 3.76system 0:13.00elapsed 56%CPU (0avgtext+0avgdata 5072maxresident)k
    1230600inputs+1200000outputs (13major+2684minor)pagefaults 0swaps
Rsync 2
    4.87user 6.52system 5:06.24elapsed 3%CPU (0avgtext+0avgdata 5076maxresident)k
    1231832inputs+1200000outputs (13major+2689minor)pagefaults 0swaps

$ rm -rf 1copy 2copy; sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Copy 1"; /usr/bin/time cp -r 1 1copy; sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'; echo "Copy 2"; /usr/bin/time cp -r 2 2copy
Copy 1
    0.48user 6.42system 5:05.30elapsed 2%CPU (0avgtext+0avgdata 1212maxresident)k
    1229432inputs+1200000outputs (6major+415minor)pagefaults 0swaps
Copy 2
    0.33user 4.17system 0:11.13elapsed 40%CPU (0avgtext+0avgdata 1212maxresident)k
    1230416inputs+1200000outputs (6major+414minor)pagefaults 0swaps

Answer 1

残りの部分は類似しているはずなので、私はあなたの例の1つだけに焦点を当てます。

この状況で問題になるのは、先読み（またはこれに関連する別の手法）機能です。

そのような例を考えてみましょう：

Ddコマンドで行ったように、 "1" dir（名前1.xmlから1000.xml）に1000個のxmlファイルを作成しました。その後、元のdir 1をdir 2にコピーしました。

$ mkdir 1
$ cd 1
$ for i in {1..1000}; do dd if=/dev/urandom of=$i.xml bs=1K count=10; done
$ cd ..
$ cp -r 1 2
$ sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy2c cp -r 2 2copy
$ sync; Sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$ time strace -f -c -o trace.copy1c cp -r 1 1copy

次のステップでは、cpコマンドを（straceで）デバッグして、データがコピーされる順序を確認しました。

したがって、cpは次の順序でそれを行います（最初の4つのファイルのみです。元のディレクトリからの2番目の読み取りは、コピーされたディレクトリからの2番目の読み取りより時間がかかるためです）。

100.xml 150.xml 58.xml 64.xml ... *この例では

次に、これらのファイルで使用されるファイルシステムブロックを確認します（debugfs出力-ext3 fs）。

元のディレクトリ：

BLOCKS:
(0-9):63038-63047 100.xml
(0-9):64091-64100 150.xml
(0-9):57926-57935 58.xml
(0-9):60959-60968 64.xml
....


Copied directory:
BLOCKS:
(0-9):65791-65800 100.xml
(0-9):65801-65810 150.xml
(0-9):65811-65820 58.xml
(0-9):65821-65830 64.xml

....

ご覧のように、「コピーされたディレクトリ」ではブロックが隣接しているため、最初のファイル100.xmlの読み取り中に、「先読み」手法（コントローラーまたはシステム設定）がパフォーマンスを向上させることができます。

ddは1.xmlから1000.xmlの順序でファイルを作成しますが、cpコマンドはそれを別の順序（100.xml、150.xml、58.xml、64.xml）でコピーします。したがって、実行すると：

cp -r 1 1copy

このディレクトリを別のディレクトリにコピーするには、コピーしたファイルのブロックが隣接していないため、そのようなファイルの読み取りには時間がかかります。

Cpコマンドでコピーしたdirをコピーすると（ddコマンドでファイルが作成されないため）、ファイルは隣接しているため、次のように作成されます。

cp -r 2 2copy 

コピーのコピーはより高速です。

概要：python/Perlのパフォーマンスをテストするには、同じディレクトリ（またはcpコマンドでコピーした2つのディレクトリ）を使用する必要があります。また、オプションO_DIRECTを使用して、すべてのカーネルバッファーをバイパスして読み取り、ディスクから直接データを読み取ることができます。

カーネル、システム、ディスクコントローラー、システム設定、fsなどの種類によって結果が異なる可能性があることを覚えておいてください。

追加：

 [debugfs] 
[root@dhcppc3 test]# debugfs /dev/sda1 
debugfs 1.39 (29-May-2006)
debugfs:  cd test
debugfs:  stat test.xml
Inode: 24102   Type: regular    Mode:  0644   Flags: 0x0   Generation: 3385884179
User:     0   Group:     0   Size: 4
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 2
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x543274bf -- Mon Oct  6 06:53:51 2014
atime: 0x543274be -- Mon Oct  6 06:53:50 2014
mtime: 0x543274bf -- Mon Oct  6 06:53:51 2014
BLOCKS:
(0):29935
TOTAL: 1

debugfs: