Charming Python: Functional programming in Python, Part 3IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
サーバーさんに本気を出してもらうために憶えておきたい設定項目
cpuspeed がオンだと.... — はせがワン (@hasegaw) 2014, 5月 29 ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。 経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。 パワーマネジメントに関する設定はオフにする UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。 Hyper Threading はレイテンシーとスループットのトレードオフ Hyper Threadingは、たぶん、コア内でパイプラインを取り合うから
＠IT：/procによるLinuxチューニング ［後編］（3/4）
/procによるLinuxチューニング ［後編］ ～ /proc/sysの主要パラメータ群総解説 ～ 遠田 耕平 2002/12/17 チューニングの実例 ここで、具体的なチューニング例を2つ紹介します。 ■ファイルI/Oのチューニング 何といってもファイルI/OはUNIXの基本操作ですので、チューニングできるとメリットがたくさんあります。 よく知られているとおり、ファイルI/Oの一番のネックはディスクアクセスです。UNIXはメモリ中の「バッファ」にデータを書き込み、そのデータを後でまとめてディスクに書き出すことで、見掛け上の性能を稼いでいます。この方式も良しあしで、あまりメモリ上に（ダーティな）データを残しておくと、システムのクラッシュの際に重要なデータが失われてしまうことにもなりかねません。そこで、UNIXシステムは常にメモリ上のキャッシュとディスク上のデータを同期させるように動作しま
IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
