[B! kernel] ikeikeikeikeのブックマーク

ikeikeikeike id:ikeikeikeike

kernelに関するikeikeikeikeのブックマーク (9)

CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
ikeikeikeike 2016/07/23
copy

linux

kernel

performance

fork

debug

CHANGE

perf

tuning

cpu
リンク
特定条件下のclone(2)を4倍速くする - 人間とウェブの未来
とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo
ikeikeikeike 2016/07/23
copy

linux

kernel

performance

fork

debug

CHANGE

perf
リンク
10GbE時代のネットワークI/O高速化
10GbE、40GbEなどの極めて高速な通信をサポートするNICが、PCサーバの領域でも使われるようになってきている。このような速度の通信をソフトウェア（OS）で処理し高い性能を得るには様々な障害があり、ハードウェア・ソフトウェア両面の実装を見直す必要がある。本セッションでは、ハードウェア・ソフトウェア両面にどのような改良が行われてきており、性能を引き出すにはどのようにこれらを使用したらよいのかについて紹介する。Read less
ikeikeikeike 2015/04/01
cpu

network

kernel

nic

slideshare

10gbe
リンク
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
ikeikeikeike 2015/04/01
cpu

network

Linux

performance

kernel
リンク
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ
社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。最近、Graphiteに保存しているデータのバックアップ︵データ同期︶に rsync 使ってて、かなり遅いので困ってた。 LISA っていう大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U
ikeikeikeike 2014/07/09
conference

HTTPS

binary

bitbucket

CPU

filesystem

rsync

Linux

kernel
リンク
2012 年 7 月 1 日のうるう秒挿入時に発生した Linux カーネルの不具合に関する情報
更新履歴 2012-08-28: URL 公開 2012-08-29: futex、hrtimer、MySQL の発生条件、NTP SLEW モードに関する @odhrfm さんからの情報、キーワード更新、その他いろいろ細かい修正 2012-08-30: 参考リンク追加 2012-09-01: LKML まとめシートの thread#50 を追加 2012-09-03: SLES カーネルの更新情報、per-cpu についての記述、blockdiag によるブロック図を追加 2012-09-11: LKML まとめシートの thread#52, #53 を追加 2012-09-12: LKML まとめシートの thread#54 〜 #58 を追加はじめに日本時間 2012 年 7 月 1 日 9:00 にうるう秒が挿入されましたが、その際 Linux カーネルに起因する不具合により、
ikeikeikeike 2012/08/29
linux

kernel

うるう秒

leapsecond
リンク
Linuxで3万（10万）プロセスを同時に起動させてみた
人間とウェブの未来︵旧︶﹁ウェブの歴史は人類の歴史の繰り返し﹂という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。といっても、きちんとした検証をしたわけではないので、あくまで﹁こういう環境でこういう事をやるとこうなる﹂という参考程度のものと理解してい頂ければ幸いです。 Linux上でプロセスは同時に何個起動できるのか数年前にC10K問題が流行りました。これは、簡単に言うと、万のオーダーでプロセスを立ち上げる事になると、現状のOSではそれを想定した設計になっていないためまともに動かなくなる、といった問題でした。だったら、﹁10万プロセス位を同時に立ち上げてみて、どうなるか試してみようぜ！﹂と思い、会社のエンジニアと一緒に試してみました。検証環境は、メモリ48GでCPUはHyperThreading込で24コアです。そこで動いていたOSはDebianでL
ikeikeikeike 2012/05/16
linux

c10k

cpu

kernel

os
リンク
［3］Linuxカーネルの“巨大なロック”が原因と判明
大規模サイトの性能改善作業とは、どういうものなのか――。リクルートの中古車情報サイト﹁カーセンサーnet﹂を全面リニューアルした体験を基に、その実態をレポートする。第1回、第2回はミドルウエアのチューニングを行った。後半はLinuxカーネルに原因があると判明するまでの調査に進む。様々なツールを組み合わせて追跡していった。中古車情報サイト﹁カーセンサーnet﹂の性能試験が本格的に始まって10日目。試験の開始当初は、ブラウザーの表示に10秒もかかるなど目標性能に遠く及ばなかった。しかし前回までで紹介したように、ファイル共有システム﹁NFS﹂の設定変更、Webサーバー﹁Apache﹂のパラメーター修正、PHPアプリケーションの見直しによって、性能は劇的に向上した。リクルート入社3年目の私は、今回の性能検証プロジェクトのリーダーとして、得意分野を持つチームメンバーと一緒に対策を進めていた。カッ
ikeikeikeike 2012/03/28
linux

kernel

tuning

performance
リンク
mixi Engineers’ Blog » Linux Programming、epollの話
お久しぶりです、初めての日本の夏に圧倒されているトールマエサカです。今日はLinuxにおけるネットワークプログラミング関連のネタです。分散データベースサーバの開発過程で最近よくLinuxのepollというイベントハンドリング機能を使っています。これがまた優秀な機能なので紹介します。このContextでいうイベントハンドラーはサーバがクライエントのリクエストを処理するためのメカニズムです。イベントの感知と通知は大雑把にいうと以下の三つの処理で構成されています：一つもしくは複数のディスクリプタを監視ディスクリプタの準備が整うまでハチ公のごとくひたすら待ち続ける準備が整ったディスクリプタの通知アプリケーションでの実装は一昔までselect(2)、もしくはpoll(2)というシステムコールで行われていました。二つとも役目は同じですがselect(2)の場合、kernelをいじらない限り
ikeikeikeike 2011/09/23
tornadoも使用しているepoll

kernel

epoll

linux
リンク
1