9/17 の Sensu Casual Talks #1 で発表された資料です。 http://www.zusaar.com/event/7607003
インフラ勉強会資料 drecomにおけるwinning the metrics battle
9/17 の Sensu Casual Talks #1 で発表された資料です。 http://www.zusaar.com/event/7607003
microインスタンスはlimitかけると大きくパフォーマンスが向上する（※再追記あり） - アルパカDiary Pro
※2014/07/02 T2インスタンスタイプとの比較 を追記しました。 ※2014/03/13 他インスタンスタイプとの比較／m3.mediumの検証 を追記しました。 こちらの記事の二番煎じです。 cgroupで、お手軽CPU使用率制限 なるほど。 リソースにLimitかけるとstealを防げるためパフォーマンスも上がるというわけですね。 どのくらい変わるのか実験してみました。 cgroup前準備 sudo yum install libcgroup sudo chkconfig cgconfig on sudo service cgconfig start cgroup設定 上記参考URLとほぼ同じ設定です。 実行時はcpu.cfs_quota_usを変動させて比較してみました。 sudo vi /etc/cgconfig.conf # 以下を追加 group limittest {
プロセスのCPU使用率を制限する方法 - Qiita
CPU負荷制限 cpulimit というツールがあり、%指定でそのプロセス(子プロセス含む)のCPUの利用率を制限することができます。例えば infinity という単にシングルスレッドで無限ループするプログラムがあったとして、CPU使用率10%で制限するには以下のようにします。 この10%というのは1論理コアの割合です。100と指定すると論理コア1個分(100%)まで許可することになります。例えば4論理コアの環境ではこの値は0～400まで設定できます。なのでシングルスレッド・シングルプロセスのプログラムであれば100以上指定しても意味はありません。 infinityを2論理コア上で50%で制限すると、以下のようになります。 (↓では論理コア全部を100%として表示してます) 既に走っているプロセスに制限をかけることもできます。
性能測定道 実践編
みなさんはApache Arrowを知っていますか？ 普段データを処理している人でも今はまだ知らない人の方が多いかもしれません。しかし、数年後には「データ処理をしている人ならほとんどの人が知っている」となるプロダクトです。（そうなるはずです。） Apache Arrowはメモリー上でデータ処理するときに必要なもの一式を提供します。たとえば、効率的なデータ交換のためのデータフォーマット、CPU/GPUの機能を活用した高速なデータ操作機能などです。 一部のデータ処理ツールではすでにApache Arrowを使い始めています。たとえば、Apache SparkはApache Arrowを活用することでPySpark（PythonからApache Sparkを使うためのモジュール）とのやりとりを高速化しています。データ量によっては10倍以上も高速になります。（リンク先の例では20秒→0.7秒と約3
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
tsc_checker - 新208.5日問題簡易チェックツール
以前情報公開した新 208.5 日問題向けに、現在の TSC 値出力や numeric overflow 警告を行うツールを作成しました。 「今動いているサーバは大丈夫なのか？」という疑問を解決するためのツールです。GCC Inline Assembler を含め Linux Kernel 内の新 208.5 日問題ロジックとほぼ同等の処理を行います。記事にも書きましたが、本問題は旧 208.5 日問題とは異なり、 uptime 結果を確認することによって問題の有無を判断することが出来ません。再起動を行っても TSC 値がリセットされないことが問題の発生要因であるためです。ご注意ください。*1 https://github.com/hisayosh/tsc_checker 目的 従来のオペレーション（再起動）による TSC 値の蓄積状況を確認する 仮の CPU クロック周波数を基に現在の
新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
sysのCPU使用率が高い場合にその内訳を調べる方法 - ablog
OSレベルで sys のCPU使用率が高い場合に perf*1 を使って、何の処理の割合が高いか調べる方法です。 perf は 特定のプロセスだけでなくOS全体の統計を見れる カーネル（sys）とユーザー（user）の両方を見れる ところが非常に便利だと思う*2。 準備 ひたすら write システムコールを発行し続けるプログラムを作成する $ cat write_loop.c #include <unistd.h> int main(void) { while(1) { write(1, "foo\n", 4); } } コンパイルする $ gcc write_loop.c -o write_loop 実行権限を付与する $ chmod u+x write_loop 検証 ひたすらwriteシステムコールを発行するプログラムを実行する $ ./write_loop > /dev/null
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://syuu1228.github.io/process_management_and_process_schedule/process_management_and_process_schedule.pdf