
数日前、Ubuntu ボックスを 13.04 から 14.04 LTS にアップグレードしました。現在は libuuid-2.20.1 を使用しています。とにかく、アップグレード後、UUID1 が非常に遅くなりました。
$ time uuidgen -t
f22c36aa-f511-11e3-9437-080027e59ea0
uuidgen -t 0.71s user 0.67s system 99% cpu 1.387 total
$ time uuidgen -t
fea4537c-f511-11e3-a6d5-080027e59ea0
uuidgen -t 0.72s user 0.67s system 99% cpu 1.394 total
0.7 秒が経過しましたuuidgen -t
。何が遅くなるのでしょうか?
- 更新しました -
これが私のw
結果です:
$ w
09:48:55 up 5 days, 22:56, 3 users, load average: 0.37, 0.43, 0.43
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
sub :0 :0 Wed10 ?xdm? 2days 22.69s init --user --state-fd 41 --re
sub pts/26 sub.local Wed18 16:47 17.00s 10.07s vim -b -b test/test_item.py
sub pts/27 sub.local Wed18 7.00s 8.63s 0.02s w
答え1
それはおそらくランダム性を引き出す/dev/ランダム(そう、私は見た)意思ランダム性を提供するのに十分なエントロピーが蓄積されるまでブロックします。エントロピーは、キーボードの使用、マウス、USB、ハード ドライブのアクティビティなどから得られます...ランダムもの。
/dev/urandom はブロックしませんが、/dev/random が提供するレベルのランダム性は提供できません。奇妙に聞こえるかもしれませんが、明らかに非常にランダムなランダム性を必要とする人がいる一方で、私は単純なランダム性で常に満足しています。
uuidgenは/dev/ランダム-r (ランダム) uuid の場合はシステム クロック (およびイーサネット MAC)、-t (時間) uuid の場合はシステム クロック (およびイーサネット MAC) を使用します。使用するクロックの粒度が十分でない場合、uuidgen は一意性を保証するために一定の最小時間が経過するまでブロックすることがあります。(これは私の推測であり、事実ではありません。申し訳ありません)。
私は自分のシステムで同じ libuuid1 ライブラリ v2.20-1 を使用しており、連続ループを実行すると、システムがランダム uuid (-r モード) をそれぞれ 0.002 秒 (2 ミリ秒) で生成し、時間ベースの uuid をそれぞれ 0.004 秒 (4 ミリ秒) で生成していることがわかります。あなたのシステムは、(多くの!) 現在、他に何がありますか? (負荷の軽い 2GHz マシンでの時刻です。)
私の 2 台の Raspberry Pi でもテストしましたが、時間ベースまたはランダム ベースの UUID の両方で平均約 10 ミリ秒 (0.010 秒) でした... システムが非常にビジーなようです。 (または、Atari 2600 で Linux を実行しているのかもしれません...)