”私の環境で”大きなテキストファイルをawkで処理するときにcatで投げ込むと速い理由 - ablog
大きなテキストファイルをawkで処理するときにcatで投げ込むと速い理由 - ablog を書きましたが、awk file > file より cat file|awk > file が速い環境は稀なようなので、私の環境でなぜ cat file|awk > file のほうが速いのか調べてみました。プロセススケジューラが関係しているようです。 ↑はPerf + Flame Graphs で、awk file > file 実行時のコールスタックと所要時間を可視化したものです。 結論(たぶん) SSDの暗号化・復号をカーネルスレッドで行なっているのと、プロセススケジューラが awk とカーネルスレッドを同じ CPU にスケジューリングしていた(他に空いている CPU があるのに)。 awk file > file では暗号化データを復号するカーネルスレッドと awk のプロセスをプロセススケ
[perl] Error in tempfile() using template /tmp/XXXXXXXXXX: Have exceeded the maximum number of attempts (1000) to open temp file/dir at hoge.pl line 14. のようなエラーが発生した場合の対処方法 - tokuhirom's blog
File::Temp を使っていると、表題のようなエラーが発生することがある。 これは一件すると、ファイルを開く処理が失敗した用に見えて、ファイル開き過ぎとかかなあと思うんだけど、実際はそういうことではないようだ。 File::Temp の実装はこのへんになっていて、要するに EEXIST が発生した場合に 1000 回ファイル名を変えてリトライして、その結果としてダメだったというときにいい感じにあがる例外である。 https://github.com/Perl-Toolchain-Gang/File-Temp/blob/master/lib/File/Temp.pm#L602 ここを見れば分かる通り、EEXIST の時だけしか次のループにいかないので、OS 的な問題ではない。 https://github.com/Perl-Toolchain-Gang/File-Temp/blob/ma
ファイルに書きこみを行ったらかならず fsync しよう - にょきにょきブログ
通常、なんの考えも無しにプログラムがファイルに書きこみを行った後、運悪くシステムがクラッシュするとファイルが失われる可能性がある。通常のファイル書き込みはファイルに書き込んでいるように見えて実はバッファがメモリ上に蓄えているだけだからだ。このメモリ上に蓄えられた、いずれストレージに書き込むデータのことをダーティページと言う。何もしなくてもダーティページに書きこまれたデータはカーネルが定期的にストレージに書き込むのだが、若干のタイムラグがある。この間にクラッシュするとデータが失われるわけだ。データが書き込んだ直後、すぐストレージに書き出したい場合は fsync システムコールを呼ぶ必要がある。 C や C++ といった低レイヤーを扱う言語なら fsync を呼ぶだけで良いが、Java のような高級言語でどうやって fsync を発動させればよいか。 通常のファイル書き込み 下記のような一般的
Javaにおけるファイルロックについて - World Wide Wonderful
いわゆるファイルロック File lockFile = new File("pid.lock"); lockFile.deleteOnExit(); while (lockFile.createNewFile()) { try { // ロックを取得している場合の処理 ... } finally { lockFile.delete(); } } else { throw new RuntimeException("ロックを取得できませんでした."); } 上記はいわゆるファイルロックと言われるものです。 マルチスレッド環境の際に同じ処理が並列に実行されるとマズい場合、ファイルロックにより同じ処理が並列に実行され内容に制御します。 File#createNewFile() は、ファイルが存在しなければ新規にファイルを作成しTrueを返し、既にファイルが存在すればFalseを返します。 ただし
そのファイル、安全に更新できていますか？（アトミックなファイル操作：前編）
ハートビーツ最年長エンジニアの滝澤です。以前、弊社CTOにシニアおっさんエンジニアから若手エンジニアに向けて何か書いてくれと言われた気がしたので、アトミック（atomic）なファイル操作について3編に分けて紹介します。この内容は弊社の社内勉強会で話した内容をまとめ直したものです。 そのファイル、安全に更新できていますか？（アトミックなファイル操作：前編）←今回 そのファイル、安全に作成できていますか？（アトミックなファイル操作：中編） そのファイル、安全にロックできていますか？（アトミックなファイル操作：後編） 今回は「みなさん、安全にファイルの更新ができていますか？」ということについて、考えてみましょう。 あなたはあるサーバ上のファイルの更新を依頼され、もらったファイルをサーバ上でコピーして上書きしました。しばらくして、データに異常が発生したので調べて欲しいと言われました。さて、何が起き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxカーネルのreadahead、うまく動いてないケースがあるのかも
http://www.nxmnpg.com/ja/8/zic
Bad file descriptor
How to use custom packages