いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方 - Qiita
さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分
MySQLをプロファイる(仮)
5. How to profile your MySQL? ● dstat -apr ● 他のサーバーと比べる時に便利 ● SET GLOBAL する時は一緒に流しておく ● 定常値的なものを把握するのに ● カーネルによっては -r 使えない ● iostat -mx ● await, svctm あたり ● I/O なのかそれ以外なのか…というあたり ● top -iH -p `pidof mysqld` ● 見るのは State くらい ● "f"=> "J"(CPU 番号 ), "P"(SWAP) 6. How to profile your MySQL? ● perf top -p `pidof mysqld` ● 役に立ったことはないけど紳士のたしなみ ● pt-ioprofile --cell sizes --run-time 10 ● どのファイルに対して I/O したか見
「超チューニング祭 ～ニコニコを超快適にしてみた～ in ニコニコ超会議３」の問題点 - Webパフォーマンスについて
来る2014年4月26日(土)・27日(日)に、「ニコニコ超会議3」が開催され、その中で「超チューニング祭 ～ニコニコを超快適にしてみた～」が開催されるそうです。 これは、現行のスマートフォンサイトのTopページのソースファイルを競技者がチューニングして、速度やデザイン・UIの改善をして、速度と使い勝手を競うのだそうです。 「これは面白そうだ! 会場は家から近いし!」と思って参加するつもりでいましたが、事前調査で計測してみた結果、フロントエンドのチューニングでは速くならないことがわかったので、その内容について説明します。 (主催者の方にも、フロントエンドのチューニングでは速くならないという情報は伝えてあります。) まずは、計測データ まずは実際のトップページ(http://sp.nicovideo.jp)の計測データを見てみましょう。 計測は、NTT DoCoMoとSoftBankの3G回
Part 1: Lessons learned tuning TCP and Nginx in EC2 « Chartbeat Engineering Blog
Part 1: Lessons learned tuning TCP and Nginx in EC2 January 2nd, 2014 by Justin Our average traffic at Chartbeat has grown about 33% over the last year and depending on news events, we can see our traffic jump 33% or more in a single day. Recently we’ve begun investigating ways we can improve performance for handling this traffic through our systems. We set out and collected additional metrics f
AWS News Blog
Announcing General Availability of Step-by-Step Guides for Amazon Connect Agent Workspace At AWS re:Invent 2022 we announced the availability of step-by-step guides for Amazon Connect agent workspace in preview. My colleagues who collaborated to write the announcement post wrote about some of the challenges that contact centers face with training new agents to get up to speed with their agent desk
基本に戻ってInnoDBの話をします
14. mysql> SHOW CREATE TABLE t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `val` varchar(32) DEFAULT NULL, UNIQUE KEY `num` (`num`), KEY `val` (`val`) ) ENGINE=InnoDB AUTO_INCREMENT=100000001 DEFAULT CHARSET=utf8mb4 1 row in set (0.03 sec) 【 innodb_buffer_pool_size= 4G 】 $ time bin/m
ファイルアクセスを高速化する方法を調べてみた - a9bのブログ
HDDの基本 http://www.systembeans.com/wiki/index.php?LinuxKernel http://www.miraclelinux.com/technet/document/linux/training/2_5_4.html http://plaza18.mbn.or.jp/~moriban/linux/HardDiskPerformance.html http://d.hatena.ne.jp/naoya/20070523/1179938637 SDD http://www.nogutetu.com/2008/09/dbhddssd.html http://akio.way-nifty.com/ja/2009/09/ssd-96c5.html http://tech.lampetty.net/tech/index.php/archives/299 h
I/Oスケジューラを使う。
(参考)LinuxカーネルのI/Oスケジューラ http://memo.blogdns.net/iosched.html 以下、上の記事の抜粋です。特に「スケジューラの種別ってなんだっけ」レベルの方は'''下の記事を鵜呑みにせず、上のリンク先に訪問して全文をお読みください''。 (ここから抜粋) Linux カーネルの I/O スケジューラ 従来は Linux カーネルの I/O スケジューラは一種類だけで、コンパイル時に固定されていました。しかし Linux カーネル 2.6.10 からは複数の I/O スケジューラをデバイス毎に切り替えて、ハードウェアや用途に最適なスケジューラを選べるようになりました。カーネル 2.6.17 に組み込まれているスケジューラは下の四種類です。 noop anticipatory deadline cfq noop スケジューラ noop スケジューラはそ
[Solaris] Solarisのパフォーマンス監視 - Life with IT
2007/8/15更新 対応バージョン: 10 Solarisシステムが正常に稼働しているかどうかを判断するには日常的な監視が欠かせない。 ここではSolarisシステムを監視するのに必要なコマンドとその結果を分析するポイントについてまとめる。 後半ではシステム性能が悪化した場合の問題点の特定から改善までの流れについて事例を交えて紹介する。 システムの稼働状況を確認するためのコマンド システム全体の稼働状況やシステムの性能悪化の原因を調査するためにはsarやvmstatコマンドを使用する。 その後psやprstatコマンドを使用し性能を悪化させているプロセスの特定を行う。 問題となっているプロセスが特定できればプロセスの見直し(優先度の変更や実行スケジュールの変更、ユーザプログラムの改善など)を行う。 特に原因となるプロセスが特定できない場合、プロセスの見直しが不可能である場合、性能の悪化
![[Solaris] Solarisのパフォーマンス監視 - Life with IT](https://cdn-ak-scissors.b.st-hatena.com/image/square/63c67004f340a9cfebe1346d512a10a786385cbc/height=288;version=1;width=512/https%3A%2F%2Fl-w-i.net%2Fimg%2Flogo_256.png)
VMWareがクソ重くて殺したくなる時に読むべきもの - いつまでもブタだと思うなよ
冗談抜きでキレそうになって、悪いのは林檎なんだけどWindowsXPとかいう何年も前のOSを動かすのにこんなにクソトロイのは何でだ。とディスクアクセスとか調べまくってたら何かゲストOSがHDDにアクセスしてないタイミングでもアクセスが発生しまくっている事を発見し、色々と検索した結果見つけたのが下記のテキスト。http://wizardbible.org/49/49.txt該当部分について、何かtxtとかそういうファイルなので消えてしまわないように転載しておく。しかし本当にこの金床って人は凄い人だ。Blogなんかに何の確証もなく「この設定を.vmxにすりゃいいよ！ ○○○ = "xxxx"」とか書いているだけの何の価値も無い情報でなく、自分の調査方法を合せて読みやすくまとめてくれている。こういう記事をブログに書いていきたいと思ったね。 x0xXx0xx0xXx0xx0xXx0xx0xXx0x
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
ke-tai.org > Blog Archive > OSC 2010 北海道の発表で使用したスライド資料「PHPで大規模ブラウザゲームを開発してわかったこと」
OSC 2010 北海道の発表で使用したスライド資料「PHPで大規模ブラウザゲームを開発してわかったこと」 Tweet 2010/6/28 月曜日 matsui Posted in PHP, お知らせ | 7 Comments » 先日6月26日、札幌で「オープンソースカンファレンス2010 北海道」が行われ、無事終了することができました。 当日は来場者数が過去最高の約450名となり、閉会式は会場に収まりきらないくらいの大盛況でした。 ご来場者の方々、スタッフ・事務局の方々、本当にありがとうございました。 私も1コマセミナー枠を戴くことができまして、弊社で「ブラウザ三国志」というゲームのプログラム開発を行った際の苦労やノウハウなどをまとめた、「PHPで大規模ブラウザゲームを開発してわかったこと」という発表を行わせていただきました。 お越しいただけなかった方のためにも、その際に使用したスライ
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
キャパシティプランニング
世界最大の写真共有サイトFlickrの技術マネージャーが、急成長するWebサイトのキャパシティプランニング（容量計画）の秘訣を披露。日々トラフィックが増加し、管理するデータ量が膨張するWebサイトでは、いかにダウンさせずに運用し、急成長に対応するかが最重要課題です。本書では、現状を分析し、限界を予測し、そして無駄なく適切にリソースを配置して対応するためのテクニックを紹介。変化に強いWebサイトの構築・運用方法を指南します。Web関連企業のみならず、すべての企業の参考となるヒントが満載です。 はじめに 本書執筆の理由 重点事項と主題 対象読者 本書の構成 本書の表記法 コード例の使用 連絡先 謝辞 1章 キャパシティプランニングにおける目標、課題、およびプロセス 1.1 間に合わせの計算 1.2 いつシステム障害が発生するかを予測する 1.3 システム統計データに「話をさせる」 1.4 物品
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[よくわかるクラウドデータベース] Amazon RDS for PostgreSQL検証報告![[よくわかるクラウドデータベース] Amazon RDS for PostgreSQL検証報告](https://cdn-ak-scissors.b.st-hatena.com/image/square/2acfb2d9a4a3f72d83035aaffad24b89be76f63f/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20140117rdsforpgsqlbenchreport-140216194106-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Amazon EC2 Technical FAQs : Articles & Tutorials : Amazon Web Services
Executing scripts on a remote machine - Marigan's Weblog
やっぱり Sun がスキ！ : Weblog vmstat コマンドの読み方