革命の日々！ Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について
なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？: http://togetter.com/li/871768 以下のように、スラドに転載されてしまったわけだ。 スラド： Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？： http://linux.srad.jp/story/15/09/09/0648258/ いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。 tcp_tw_inter
革命の日々！ transparent hugepage considered harmful
タイトルは釣りです。はい。 現状、ありとあらゆるDBがTHPをdisableするよう推奨している。これはあんまり良い状況じゃないのでTHPを disabled by default に変えようという提案。 Ted Ts'o はデフォルトがenabledだから、パフォーマンスが良くなるケースが気づきにくいだけだろうと主張。まあ、そうだろうね。KVM hostとかだと anon ばっかりつかうし、guest OSでメモリ制限あるから、hostのreclaimは走らないしで、悪いケースになりにくそう。 Vlastimil Babka はそもそも page faultの延長で、コンパクション始めちゃうのがよくないので、デフォルトは今より less aggressiveであるべきという意見のようだ。 Googlerが今のままがいいと主張していて、エンタープライズ屋さんが変えたいという陣営なのかな。
革命の日々！ おまえら rpmdev-setuptree を使えという話
いままで、rpmbuildするときに mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} して、 echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros とかやってたんだけど、それはもう古いらしい。 % yum install rpmdevtools % rpmdev-setuptree すると、上記の両方をやってくれるのに加えて .rpmmacrosに並列処理設定を追加してくれる。 こんな感じ %_topdir %(echo $HOME)/rpmbuild %_smp_mflags %( \ [ -z "$RPM_BUILD_NCPUS" ] \\\ && RPM_BUILD_NCPUS="`/usr/bin/nproc 2>/dev/null || \\\ /u
革命の日々！ メッセージペディアのpage allocation failureの説明
http://ossmpedia.org/messages/linux/2.6.9-34.EL/482.ja 物理ページの確保に失敗した。要求したサイズと確保時に指定した空きページの探索方法を表示する。 物理メモリが不足している場合に発生する。また，空きメモリが充分であっても，物理メモリが断片化し要求サイズ分の物理ページが連続して確保できない場合は発生する。 うーむ、この説明だと普通のときは出ないメッセージであるかのように書いてあるが、んなこたーない。 ネットワーク系のドライバだとパケット受け取った時に、そのデータを格納する用のメモリ確保を行うことが多いのだが、そのときに使われる関数 netdev_alloc_skb() は __GFP_NOWARN を立てない。 かつ、Linuxはメモリ管理哲学としてぎりぎりまでメモリを開放せずにキャッシュとして使い続け、メモリ確保要求が来てから開放する
革命の日々！ muninのプラグインを書いてみた
最近、kosakiという人が「オレはLKMLでもっとも頻繁にOOMバグの解析を行っているデベロッパの一人である。オレが言うんだから間違いない。現在のOOMの表示と/proc/meminfoはフィールドが足りない」と真偽が定かではない主張をして、フィールドを大量に増やすパッチを、ねじ込んだ。 ちなみに、現在の /proc/meminfoはこんな感じ $ cat /proc/meminfo MemTotal: 6037184 kB MemFree: 1229820 kB Buffers: 252336 kB Cached: 3673464 kB SwapCached: 0 kB Active: 1463432 kB Inactive: 2772100 kB Active(anon): 315332 kB Inactive(anon): 16 kB Active(file): 1148100 k
革命の日々！ RHEL6 S390用チューニングパラメタ推奨値解説
RHEL6のドキュメントページ（※）みてたのだけど ※ http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/ Technical Notes: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Technical_Notes/index.html に面白いチューニングパラメタの記述をみつけたので解説してみる。S390向けのチューニング推奨値の部分だ ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー System z Performance Some of the default tunables in Red Hat Enterprise Linux 6 are curr
革命の日々！ RHELのSRPMの置き場所
革命の日々！ Home ＞ RHELのSRPMの置き場所 プロフィール Author:kosaki 連絡先はコチラ ブログ検索 最近の記事 引っ越しました (12/30) THPの記事にちょっと追記した (09/10) Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について (09/09) transparent hugepage considered harmful (09/02) sosreportで OpenStackのログ (07/20) robocopy の使い方 (12/12) Windows 再インストールした (11/20) RHELのO_SYNCって面白い事になってるんだなあという話 (10/21) RHEL7でスクリーンセーバー無効化 (09/03) commit 直前にChangeLogの日付を変更する (08/15) 最近のコメント て
革命の日々！ XFS on x86_64
XFS on x86_64はまったく実用的ではないとかなんとかいう議論をLKMLでしている。XFSって１ページ 書き出すだけでもスタック3.5Kも使うのよね。カーネルスタックはページサイズx2なので8Kしかない。 よって なんか色々処理 +- kmalloc +- メモリ不足なので回収 +- pageout +- writepage + kmalloc +- このへんでさらに割り込み とか考えるとあきらかに突き破っていて、LVMやMDやNFSを使うとそんな複雑なパターンを 考えなくても正常系で普通に突き破るという。David Chinnerが既知の問題で直せないと 言っているからには、本当にダメなんだろう。 世間の人がどうやって回避しているのか知りたいものである。
革命の日々！ FSベンチマーク対決
http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1 たぶん、デフォルトパラメタで勝負しているので、ext3はwritebackモードだと思う。 要約 ・SQLiteテストはext3が20秒で終わるところが、ext4では870秒、btrfsに至っては1472秒もかかった ・PostgreSQLのpgbenchのbtrfs, XFSは完走できなかった ・IOZone Write: ext3:107MB/s, ext4:131MB/s, Btrfs:89MB/s Read: ext3:202MB/s, ext4:219MB/s, Btrfs:93MB/s Btrfs遅いな～ ・Dbenchはext3:100MB/s, ext4:32MB/s, Btrfs:46MB/s やはり、ordered-mod
革命の日々！ [linux-btrfs] btrfs vs ext4 benchmark
IBMのサーバでbtrfsとext4のベンチとったらbtrfsはクソ遅かったぜ。という話。 Hi, here are some tests on an IBM server with btrfs vs. ext4. Kernel: 2.6.29.1 Benchmark software: compilerbench with options -i 10 -r 30 CPU: Intel Xeon Quadcore E5310 Chipset: Intel 5000 Memory: 4 GB FB-DIMM DDR2-667 HDDs: 2x WD6400AAKS @ Raid0 Storage Controller: IBM Serveraid 8k btrfs Result: intial create total runs 10 avg 50.89 MB/s (user 0.85s s
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
