5

私はLinux、nfsを使用しており、複数のマシンが関係しています。

fcntlを使用してファイルロックを実装しようとしています。同じマシン上のプロセス間でのみ機能することがわかるまで、flockを使用していました。

F_SETLKWを使用してfcntlを呼び出すと、perlアラーム（タイムアウトを追加するため）が以前のように機能しなくなりました。これは通常は問題ありませんが、ctrl-cも実際には機能しません。

私が起こっていると私が信じているのは、fcntlが30秒ごとに信号をチェックしているだけだということです。アラームは最終的には戻ります。ctrl-cがキャッチされました...最終的に。

fcntlがこれらの信号をチェックする頻度を調整するためにできることはありますか？

4

1 に答える 1

1

私は間違いなくこの問題の専門家ではありませんが、私の知る限りfcntl、あなたが述べたように、あなたの場合はうまくいきません. fcntl アドバイザリ ロックは、同じマシン内でのみ有効です。

トピック外の場合は忘れてください。File::NFSLockを使用して、キャッシュ ストーム/ドッグパイル/スタンピングの問題を解決しました。複数のアプリケーション サーバーが NFS ボリュームでキャッシュ ファイルの読み取りと書き込みを行っていました (あまり良いアイデアではありませんが、最初はそのように考えていました)。

File::NFSLock をサブクラス化/ラップして、その動作を変更しました。特に必要なもの：

  • File::NFSLock オブジェクトが範囲外に出ても消えない持続的なロック。通常の File::NFSLock を使用すると、オブジェクトが範囲外になるとロックが解除されます。これは私が必要としていたものではありませんでした。
  • 実際のロック ファイルには、ロックを取得したマシンの名前も含まれています。プロセス ID だけではプロセスが終了したかどうかを判断できないことは明らかなので、ロックファイルを安全に盗むことができます。そこで、コードを変更して、ロックファイルmachine:pidを単にpid.

これは数年間素晴らしく機能しました。

リクエストの量が 10 倍になるまで。つまり、先月、非常にビジーなキャッシュ ファイルが 2 つのバックエンドによって同時に書き込まれ、デッド ロックが残るという最初の問題を経験し始めました。これは、1 日あたりの全体的なページビューが約 900 万から 1000 万に達したときに発生しました。

最終的に破損したキャッシュ ファイルは次のようになります。

<!-- START OF CACHE FILE BY BACKEND b1 -->
... cache file contents ...
<!--   END OF CACHE FILE BY BACKEND b1 -->
... more cache file contents ... wtf ...
<!--   END OF CACHE FILE BY BACKEND b2 -->

これは、2 つのバックエンドが同時に同じファイルに書き込みを行った場合にのみ発生します... この問題が File::NFSLock + 私たちの mod またはアプリケーションのバグによって引き起こされているかどうかはまだ明らかではありません。

結論として、あなたのアプリがひどくビジーでトラフィッキングされていなければ、File::NFSLock を選んでください。それが最善の策だと思います。それでも NFS を使用しますか?

于 2010-10-30T08:55:43.540 に答える