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に起因する高負荷問題から、システムコールやカーネ
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
まずやっとくPostgreSQLチューニング
1. Copyright © 2014 K.K.Ashisuto All Rights Reserved. 1 まずやっとく PostgreSQLのチューニング 日本PostgeSQLユーザ会 喜田 紘介 2014/07/13第4回 中国地方DB勉強会 2. Copyright © 2014 K.K.Ashisuto All Rights Reserved. 2 自己紹介 ● 名前 ● 喜田 紘介(きだ こうすけ) ● 所属 ● 日本PostgreSQLユーザ会 広報・企画担当 ● 株式会社アシスト データベース技術本部 ● 近況 ● 2014年度より、JPUGの理事になりました。 ● 仕事では、新規構築するシステムのDBをどうすべきか？というRDBMS選択支援や、 商用DBからOSSへの移行の前段階として、オブジェクトやSQL差異のレクチャーや、 データベースの診断・評価を行う 移行アセ
Goでアロケーションに気をつけたコードを書く方法 : DSAS開発者の部屋
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
Dockerで実現するリアルタイムシステムのためのプロセスパーティショニング - 技術部門のBlog
「パーティショニング」はリアルタイムシステムや高信頼システムを構築する上で、あると便利なプロセスを隔離する機能です。 今回は「Docker」の内部で使われているLinux軽量コンテナ技術を使って簡易的なパーティショニングを実現します。 DockerはWebの世界で極めて高い注目を集めている強力なコンテナ構築環境です。知能ロボットなど複雑なソフトウェアの組み合わせからなるリアルタイムシステム構築でもその強力な機能が使える可能性を示すことができればと思います。 リアルタイムというと「とにかく処理を速くする」というイメージがあるかもしれませんが、ロボットにおけるリアルタイムとは「処理を決められた時間に始めて決められた時間までに確実に終わらせること」を指します。例えば、自動走行車における操舵やブレーキは時間に遅れてしまうと事故を招きます、これはリアルタイムです。一方で、ビットコインのマイニングのよ
Apacheチューニング
2. チューニング • KeepAliveの設定 • コンテンツの圧縮転送 • 不要モジュールの削除 • シンボリックリンク先の参照許可 • TimeOutの設定 • DNS問い合わせの無効 • .htaccessの無効化 • Prefork MPMのチューニング • Worker MPMのチューニング 3. KeepAliveの設定 ディレクティブ 値 説明 KeepAlive On 同一クライアントに対し コネクションを使い回す MaxKeepAliveRequests 1ページあたりの平均 的なコンテンツ数 + α 1つのKeepAliveで受け付け るリクエスト数 KeepAliveTimeout 1ページ当たりの平均 的な転送時間＋α クライアントからのリクエ ストがなくてもKeepAliveを 維持する秒数 5. 不要モジュールの削除 デフォルトでは多くの拡張モジュー ルが組み
実例Javaトラブルシューティング！ 〜稼働中のシステムを立て直した半年間の軌跡
2. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 自己紹介 2 • 谷本 心 (Shin Tanimoto) - Acroquest Technology株式会社 - 開発＆トラブルシュート教育 - JavaOneスピーカー - JJUG / 関ジャバ / S2JSFコミッタ - Twitter : @cero_t (日本語) - Facebook : shin.tanimoto (英語) 3. Copyright © Acroquest Technology Co., Ltd. All rights reserved.Copyright © Acroquest Technology Co., Ltd. All rights reserved. 世の中のシステムは 完璧だろうか？ 3 4. Copyrigh
第2回 memcachedのメモリストレージを理解する | gihyo.jp
株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ
ruby/ruby#495日本語解題
三行で卜部って口だけ野郎でどうせたいしたもん書けないんでしょ? [1] [2]→ 見せてやんよゴラァ→ ごらんの有様教訓: 陰口は本人に聞こえない所で。さすがに名指しはまずい。 どういうパッチかRubyのオブジェクトサイズを変更(大きく)する。そのことにより第一義的にはCPUキャッシュミスヒットが削減される。副次的作用として大きくなった余剰の領域にデータを詰め込めるので中間構造体を減らしてメモリアロケーションが最適化される。それらの総合的な結果として全体に高速化する。 前史とはいえこのアイディア、べつに最近涌いて出たものでもない。というか、俺がまだ大学院でNetBurstと戯れてたころの発想だから、かれこれ7～8年物だな。しかもこの間べつに秘密にしてたわけでもなくて、Rubyのオブジェクトって素数幅でいくなくね?ってのは、わりと口頭では折に触れて言ってたので、聞いたことがある人もいるはずか
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails高速化戦略 / Speeding Up Rails
MySQL 初めてのチューニング
Build and implement a single sign-on solution