wkhtmltoimage を使用してサーバー側のレンダリングを行っていますが、実行ごとに「88% の読み込み」で 1 ～ 2 分間ロックアップします。strace を介して何が起こっているのかをデバッグすることにしましたが、完全に奇妙なひねりで、プログラムはロックアップしませんでした。これは完全に再現可能で一貫性があることがわかりました。本来ならプログラムを遅くすべきなのに、なぜ strace がプログラムを速くするのでしょうか?!
strace なしで実行:
user@server:~/public_html/shapes$ time wkhtmltoimage --disable-smart-width --width 970 --format jpg '[THE URL]' '[THE PATH].jpg'
Loading page (1/2)
Rendering (2/2)
Done
real 1m45.724s
user 1m42.887s
sys 0m0.623s
STrace で実行:
user@server:~/public_html/shapes$ time strace wkhtmltoimage --disable-smart-width --width 970 --format jpg '[THE URL]' '[THE PATH].jpg'
execve("/usr/local/bin/wkhtmltoimage", ["wkhtmltoimage", "--disable-smart-width", "--width", "970", "--format", "jpg", "[THE URL]"..., "[THE PATH]"...], [/* 21 vars */]) = 0
brk(0) = 0x311a000
...
exit_group(0) = ?
+++ exited with 0 +++
real 0m6.526s
user 0m0.582s
sys 0m0.377s
サーバーは非公開なので、URL と PATH を編集しましたが、それ以外は正しい出力です。また、両方の実行で正しい出力が作成され、キャッシュの問題ではないことを確認するために一時ファイルをクリアしました。ランダムなアーティファクトではないことを確認するために、これらの実行をそれぞれ10回実行しましたが、一貫して発生します。したがって、唯一の論理的な結論は、straceがwkhtmltoimageの動作を何らかの形で変更していることであり、誰かが教えてくれることを本当に望んでいました。strace がプログラムをロックアップさせない理由を知っていれば、おそらく解決策を見つけることができます。
ハングしたプロセスは次のとおりです。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
772 sigapp 20 0 1485600 45760 14524 R 99.8 2.2 0:57.02 wkhtmltoimage
ルートとして、ハングしたイメージにアタッチできますstrace -p $(pidof wkhtmltoimage)。結果は次のとおりです。
gettimeofday({1436692542, 446246}, NULL) = 0
gettimeofday({1436692542, 556958}, NULL) = 0
gettimeofday({1436692542, 557161}, NULL) = 0
gettimeofday({1436692542, 659238}, NULL) = 0
gettimeofday({1436692542, 771381}, NULL) = 0
gettimeofday({1436692542, 771686}, NULL) = 0
gettimeofday({1436692542, 875783}, NULL) = 0
gettimeofday({1436692542, 987490}, NULL) = 0
gettimeofday({1436692542, 987781}, NULL) = 0
gettimeofday({1436692543, 84764}, NULL) = 0
...
システム: Linux サーバー 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (2 CPU Xen ゲストで実行)
ソフトウェア: wkhtmltoimage 0.12.2.1 (qt にパッチを適用) <-公式 Web サイトから .deb ファイル経由でインストール
私はこれを読みましたが、関連するかどうかはわかりません: strace に接続されている場合、ハングしたプロセスが再開します
アップデート：
別のプログラムwebkit2pdfで試してみたところ、ロックアップも見られました。今回の strace 出力は異なります。どちらのプログラムも webkit を使用します。
root@server:~# strace -p `pidof webkit2pdf`
Process 4699 attached
restart_syscall(<... resuming interrupted call ...>
の実行が成功すると、strace wkhtmltoimage ...同様の呼び出しが表示されますが、mmap が先行するほど多くはありません。
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f9dbbbc1000
gettimeofday({1436696839, 361942}, NULL) = 0
gettimeofday({1436696839, 362254}, NULL) = 0
gettimeofday({1436696839, 362505}, NULL) = 0
gettimeofday({1436696839, 362787}, NULL) = 0
gettimeofday({1436696839, 363172}, NULL) = 0
gettimeofday({1436696839, 363568}, NULL) = 0
gettimeofday({1436696839, 363913}, NULL) = 0
mmap(NULL, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f9db5000000
gettimeofday({1436696839, 364701}, NULL) = 0
mmap(NULL, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f9db4ff9000
gettimeofday({1436696839, 365612}, NULL) = 0
gettimeofday({1436696839, 365956}, NULL) = 0
したがって、以下のpvgのコメントによると、これはおそらくsetAttribute正常に動作しない場合と正常に動作しない場合のロックメカニズムですstrace。