[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading To: debian-user@lists.debian.org, debian-devel@lists.debian.org Subject: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading From: Henrique de Moraes Holschuh <hmh@debian.org> Date: Sun, 25 Jun 2017 09:19:36 -0300 Message-id: <[🔎] 20170625121936.GA7714@khazad-dum.debian.net> This warning advisory is relevant for
libeatmydataを使ってpostfixを劇速にする [用法用量要確認] - Hateburo: kazeburo hatenablog
libeatmydataというLD_PRELOADを使って、起動したプロセスのfsyncを無効化するライブラリがあったので試してみています。 libeatmydata - disable fsync and SAVE! fsyncがないと何が嬉しいかというとクラウドのようなIOまわりの環境が弱いところで、安全性は若干犠牲になりますが、パフォーマンスを稼ぐことができるようになります。 まず perlでfsyncを発行してどうなるかstraceをつかって確認してみます。 libeatmydataなし $ strace perl -MIO::Handle -e 'open(my $fh,">:unix","test.txt"); print $fh "test"; IO::Handle::sync($fh);' open("test.txt", O_WRONLY|O_CREAT|O_TRUNC,
![libeatmydataを使ってpostfixを劇速にする [用法用量要確認] - Hateburo: kazeburo hatenablog](https://cdn-ak-scissors.b.st-hatena.com/image/square/4c37033d891150fe4f57e3061309374a5a0c059b/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fkazeburo%2F20161111%2F20161111142853.png)
conntrack がロードされたサーバで LVS-DR を構成する場合の注意点 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。インフラ開発チームの深谷です。 Linux の conntrack モジュールがロードされたサーバーで、レイヤー4 (L4) ロードバランサを LVS-DR で構成したところ、 パケットフィルタが正常に働かず、通信はできるものの、一部のパケットは落ちるという挙動に悩まされました。 今回はこの問題について詳細に解析し、原因と対策がわかったのでご紹介いたします。 発生した問題 今回の問題は、Ubuntu を使って L4 ロードバランサを実装している時に遭遇しました。 構築したロードバランサには、セキュリティ対策のため iptables のラッパーである UFW を使って、 パケットフィルタをかけていました。 ロードバランサの実装には、Linux カーネルに実装されている LVS を使いました。 LVS ではいくつかのパケット転送方式をサポートしており、今回はパフォーマンスに優れる
ファイルシステムの動作がLinuxカーネルによって違うというお話、とか色々
先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると： ファイルシステム上に書き込み可能な状態でファイルをオープンする。 一定ペースで、ファイルへ Buffered I/O で書き込み。 ファイルをクローズする。 このとき、特定条件下のXFSでは、（２）の段階では全然フラッシュが発生せず、（３）の段階でまとまったフラッシュが発生するのだそうです。 ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション（ミドルウェア）からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linux
CloudForecast のCPU使用率グラフで SoftIRQ(Software interrupts) がでるように修正した - blog.nomadscafe.jp
CPUの使用率のグラフからSoftIRQ(Software interrupts)が抜けてしまっていたので追加して、いくつか修正を加えた。 ↑午前2時ぐらいからちゃんとでるようになってる。通信が多いサーバではインパクトがある変更かもしれません。 Net-SNMP(UCD-SNMP-MIB)のCPU使用率に関する項目は UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 428160510 UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 381268 UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 95049839 UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 1753791119 UCD-SNMP-MIB::ssCpuRawWait.0 = Co
Optimising NginX, Node.JS and networking for heavy workloads
9 Min Read Optimising NginX, Node.JS and networking for heavy workloads Used in conjunction, NginX and Node.JS are the perfect partnership for high-throughput web applications. They’re both built using event-driven design principles and are able to scale to levels far beyond the classic C10K limitations afflicting standard web servers such as Apache. Out-of-the-box configuration will get you prett
bcache
Bcachefs Bcache is done and stable - but work hasn't stopped. Bcachefs is the hot new thing: a next generation, robust, high performance copy on write filesystem. You could think of it as bcache version two, but it might be more accurate to call bcache the prototype for what's happening in bcachefs - incrementally developing a filesystem was part of the bcache plan since nearly the beginning. It's
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sonots/growthforecast-tuning: GrowthForecast/RRDtool チューニング秘伝の書