私のサーバーには次の要件があります。
1)サーバーへの新しい接続ごとに、一連のNposix_fadvise呼び出しがトリガーされます。2)接続ごとの最初の数回のfadvise呼び出しはできるだけ早く発生する必要があります。3)クライアントが後続の要求を行った場合にfadvise呼び出しを並べ替える機能。
私が考えているのは、共有キューを備えたスレッドプールで、スレッドプールのサイズは約100です。他に何か提案はありますか?
私のサーバーには次の要件があります。
1)サーバーへの新しい接続ごとに、一連のNposix_fadvise呼び出しがトリガーされます。2)接続ごとの最初の数回のfadvise呼び出しはできるだけ早く発生する必要があります。3)クライアントが後続の要求を行った場合にfadvise呼び出しを並べ替える機能。
私が考えているのは、共有キューを備えたスレッドプールで、スレッドプールのサイズは約100です。他に何か提案はありますか?
あなたが話していると仮定してPOSIX_FADV_WILLNEED
:
posix_fadvise
すでに非同期です。つまり、カーネルの機構を起動してバックグラウンドでデータのページングを開始しますが、実際にはデータが読み取られるのを待機しません。すぐに戻ります。
言い換えると、posix_fadvise
はすでに同時実行メカニズムであるため、独自のスレッドを生成してそれを呼び出すことは無意味です。また、呼び出しを「並べ替える」方法はありません。カーネルに渡されると、カーネルはディスクアクセスを並べ替える方法について独自の判断を下すからです。
本当に自分でロールしたい場合は、スレッドにブロックread()呼び出しを繰り返し実行させて、小さいブロック(8kなど)を読み取ります。(つまり、同じ8kバッファーに繰り返し読み込まれます。同じバッファーを使用すると、L1キャッシュに保持され、メモリバスを不必要に叩くことがなくなります。)これにより、ページキャッシュにデータが入力され、発生するタイミングをある程度制御できます。
私はあなたのアプリケーションがそのようなメカニズムを必要としていることに少し懐疑的ですが...
There is no point in having multiple threads blocking in fadvise
at the same time for the same underlying device, since they're all sharing the same request queue anyway.
This means that you should only need a single readahead thread, that takes readahead requests from a queue and executes them sequentially.