6

Using the exact same code, it takes about 50ms every call to a logger method (such as logger.debug) on the server, while on the dev machine it's less than 1ms. The loggers are outputting to files, with a little bit of formatting.

Other than the slowdowns with logging, the server is twice as fast.

I'm developing on Ubuntu 11.04 (Gnome) running inside VMWare on Windows 7. The server is running Ubuntu Server 11.04 (no GUI, pure console). The logging module is the official "logging" module ("import logging ... logger = logging.getLogger('mylogger')").

Any idea what could be causing this? It is extremely frustrating!

Thanks for any help!

EDIT: Both machines return "Python 2.7.1+" for their version. Both machines are running 64-bit Ubuntu.

Hard drive configuration the server is software RAID-1, while in the dev computer just a single drive.

EDIT2: Accepted Fabian's answer as it was thorough, although it didnt't quite solve the problem.

Solution: Writing to the console, period, is extremely slow. I tested writing X to file, and writing X to the console, and it was about 100x slower to the console. I don't know why that would be, but I just ran what I was running with ssh from another computer and everything was solved.

4

1 に答える 1

6

コメントに記載されているように、考えられる理由は、開発 VM と運用マシンのディスク速度の違いです。両方のシステムに同じ種類のドライブがありますか? SSD、SATA 対 SCSI、スピンドル速度とキャッシュなど? あなたの環境は、IO の点でかなり異なります。デスクトップ Windows と VMWare は積極的なディスク キャッシュを使用しますが、本番 Linux マシンは安全側でエラーを起こし、データがより頻繁にディスクにコミットされるのを待ちます。おそらく、Windows マシンには、サーバーが最適化されていない状態で実行されているときに、そのディスクの種類により適したドライバーが搭載されているのではないでしょうか? ファイル システムの違いも大きく、おそらくハードウェアが大きく異なるため、IO 速度に大きな違いが生じる可能性があります。また、CPU と RAM の速度に大きな違いがある場合もあります。最近のデスクトップ マシンは実際の速度に重点を置いていることが多く、サーバー ハードウェアは信頼性に重​​点を置いています。セットアップを最もよく知っているのはあなたなので、おそらくハードウェア パフォーマンスに関して 2 つのシステムを比較することができます。

それを超えて、実際に何が起こっているのかを知る方法は次のとおりです。

まず、ロギングをテストするために MWE を作成します。実際のコードに基づいて、同様の方法でロギングを使用する必要がありますが、ここに小さな例を示します。

import logging

logging.basicConfig(filename="test.log", level=logging.DEBUG)
logger = logging.getLogger("testlogger")

for i in range(0, 1000000):
    logger.info("iteration: %d", i)

次に、開発マシンと運用マシンの両方で、cProfile の下でスクリプトを実行します。問題の場合と同じファイルシステムに必ずログを記録してください。そうしないと、結果が当てはまりません。

python -m cProfile testlogging.py

次のような出力が得られます。

57000501 function calls in 137.072 seconds

Ordered by: standard name

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    1    0.000    0.000    0.000    0.000 UserDict.py:4(__init__)
    1    0.000    0.000    0.000    0.000 __init__.py:1044(_fixupParents)
    1    0.000    0.000    0.000    0.000 __init__.py:1085(Logger)
    2    0.000    0.000    0.000    0.000 __init__.py:1100(__init__)
    1    0.000    0.000    0.000    0.000 __init__.py:1112(setLevel)
.....    .....    .....    .....    ..... ...............................

これにより、実稼働マシンの速度低下の原因がわかるはずです。特に探すべきもの：

  • {method 'write' of 'file' objects}と を読んでいる行を探し{method 'flush' of 'file' objects}ます。これにより、Python がファイルへの書き込みとデータのディスク (この場合はログ ファイル) へのフラッシュに費やした時間がわかります。2 つのマシンに大きな違いはありますか? もしそうなら、それは間違いなく IO (ディスク) 速度の違いです。次に、サーバーのディスク設定を調べて、ディスク パフォーマンスを向上させるためにできることがあるかどうかを確認する必要があります。
  • percall最初の列が特に大きい行を探します。この列は、関数で費やされた合計時間をその関数の呼び出し回数で割ったものです。2 つのマシンを比較すると、違いの原因がわかる場合があります。
  • tottime列が特に大きい行を探します。この列は、関数で費やされた合計時間です。繰り返しますが、2 つのマシンを比較すると、速度の違いのいくつかの理由がわかる場合があります。

ディスク IO が問題であると思われる場合は、ファイルへの生の書き込みだけで追加のテストを行うことができます。おそらく、ディスクのスループットをテストできるベンチマーク プログラムを見つけることができますが、フォーマットされていないデータをファイルに書き込む単純な C (または Python) プログラムを作成して、違いが純粋なディスク パフォーマンスであることを確認することもできます。

最後に 1 つだけ注意してください。パフォーマンス テストは、プログラミングと同じように、芸術、科学、工学の組み合わせです。従うべきパターンやアドバイスはありますが、すべてのケースを解読するには少しの創意工夫が必要です。だまされないように、いろいろやってみて、楽しんでください！幸運を！

于 2012-07-18T06:12:37.163 に答える