メモリいっぱい空いてるのにswapがどんどん増える怪現象？！ - クラウドインテグレーションサービス「雲斗」のブログ
クラウドインテグレーションサービス「雲斗」のブログ 芝公園にある創研情報株式会社がAWS を 中心にクラウドの基本から便利な使いかたまでをお伝えしていきます。 とあるCentOS7のサーバにおいて、メインメモリがあまり使われず、Swap領域がどんどん増えてくる事象を確認。 DBとしてMySQLは起動してるものの、Swapにデータが展開されるほど大きなプロセスは動いてないはずなんだけど・・・ よくよく調べてみると、最近のCentOS(おそらくRed Hat Linuxも同じ)ではOSレベルでSwapの利用頻度を制御できるようで、今回のサーバはこの設定をデフォルトのまま変更していなかったため、この事象が発生したようです。 ここでは、その対策として行ったことを展開してみます。 ------------------------------------------------------------
SystemTapで真犯人を捕まえろ！
SystemTapで真犯人を捕まえろ！：Linuxトラブルシューティング探偵団 番外編（3）（1/4 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。 Web：福山義仁 俺は、福山義仁。Web技術の達人さ。Apache
プロセスにもslabにも記録されないメモリ使用領域を調べてたら、zfsのarcサイズ設定が原因だった話
概要 自分で構築したProxmox VE(PVE)のwebコンソールを眺めていたら、 4GBメモリのVMを4台しか起動していないのに仮想ホストでは48GB中37GBもメモリが使用されていた。 それの原因を突き止めるために調べていたらzfsが原因ということが判明した。 何も知らず、何も気にせず、zfsでPVEを構築していたら気付かない事象だと感じたのと、 メモリについて知ったことが多いため記事にした。 調査1(ホスト再起動) 困った時はホスト再起動するのが一番ということで、まずは再起動。 再起動後はメモリをほとんど使用されていなく、VM起動してもVMのメモリ領域くらいしか使われていない。 これで解決したと思い放置していたら、いつの間にかメモリ使用量が増えている。 なので変なプロセスがいるとかではなく、何かが起きていることがわかった。 調査2(プロセス確認) まずはメモリ使用量を確認する。 /
プロセスのVSZ,RSSとfree,meminfo挙動を実機で確認 - のぴぴのメモ
1.はじめに 1-1.この記事の要旨 1-2.(予習)メモリに関する指標とlinuxのメモリ挙動について 2.検証環境と検証方法 2-1.検証環境 2-2.検証方法 2-3.測定方法 (1)psコマンドによるVSZ,RSS情報の取得 (2)freeコマンドとmeminfo情報の取得 3.結果 3-1.全体の結果 3-2.プロセスのVSZ/RSS挙動 ポイント① malloc()した時の挙動→VSZのみ増加 ポイント② 1回目のデータread時→RSSは増えない ポイント③ データwrite→RSSが増加する 3-3.システムワイドな挙動(freeコマンド/meminfo) ポイント① malloc()した時の挙動→usedもAnonymousPageも増えない ポイント②1回目のデータread時→変化しない。 ポイント③ データwrite→used上昇、AnonymousPage上昇 4.
ソケット通信 possible SYN flooding on port 443. Sending cookies. がログに出てきた - Qiita
ソケット通信 possible SYN flooding on port 443. Sending cookies. がログに出てきたLinux はじめに インターネットに公開しているホームページが突然閲覧できなくなりました。サーバではロードアベレージも低く、負荷はかかっていないようでした。今回の記事ではこの状況下でのボトルネックの確認＆対応方法について簡単にまとめてみました。 環境 CentOS6 Apache 参考 https://qastack.jp/server/294209/possible-syn-flooding-in-log-despite-low-number-of-syn-recv-connections https://github.com/hiboma/hiboma/blob/master/kernel/net/net-backlog.md https://qiit
IO待ちメモ - Qiita
概要 IO待ちについて自分で調べた自分めも。 vmstat wa列 絵で見てわかるシステムパフォーマンスの仕組み より ディスクIO待ちのwaはCPU使用率が上がると自然と減ってしまうものです。I/O待ちについてはb列を活用しましょう。 waはあくまでもCPUがアイドルであり、そのCPUに紐付くI/O待ちスレッドがあるときにカウントされる wa列は要注意です。一般にI/O待ちの指標と思われていますが、I/O待ちが増えるとwa列が上がる傾向があるものの、必ずしも上がるとは限らない情報だからです 絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection) より スリープしているプロセスの中には、I/O待ちをしているものもある。その場合、「wa(waitI/O)」として現れることが多い。多くのOSでは、CPUがアイドル(id)であり
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 の状態をさらに詳しく確認 おおよその原因特定から設定を
【 pidstat 】コマンド――プロセスのリソース使用量を表示する
Linux基本コマンドTips一覧 本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介してきます。今回は、プロセスごとCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 pidstatコマンドとは？ 「pidstat」はプロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示するコマンドです。 pidstatはmpstatコマンド（第127回）やiostatコマンド（第128回）と同じsysstatパッケージに収録されています。いずれも、主に/var/log/sysstatを参照するコマンド群です。 sysstatパッケージがインストールされていない場合、「sudo yum install sysstat」あるいは「sudo apt-get install sysstat」などでインストールできます ※。
Linux の iostat の出力結果を銀行のATMに例えて説明してみる - ablog
vmstat の"r"列とマクドナルドのレジカウンター - ablog の iostat 版です。 以前、iostat の見方 - ablog というエントリを書きましたが、 絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection) 作者: 小田圭二出版社/メーカー: 翔泳社発売日: 2008/04/22メディア: 単行本（ソフトカバー）購入: 22人 クリック: 303回この商品を含むブログ (36件) を見るP.176 LIST 1 Linuxのiostat -x 30の出力結果を分析 を元に説明してみます。 $ iostat -x 30 avg-cpu: %user %nice %sys %iowait %idle 15.46 0.23 3.70 45.05 35.55 Device: rrqm/s wrqm/s r/
sarコマンドでディスクIOを見る - ike-dai's blog
sar -Aで取得したシステムの利用状況の中で、ディスクIOを示すものは下記の記述部分。 17:57:57 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 17:58:07 dev8-0 8.78 0.00 134.13 15.27 0.01 0.73 0.73 0.64 17:58:07 dev8-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 17:58:07 dev8-2 8.78 0.00 134.13 15.27 0.01 0.73 0.73 0.64 17:58:07 dev8-16 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 17:58:07 dev8-17 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0
せっかくだから sar についてもメモ - あしのあしあと
この時は、結果をファイルに残すために、結局（あきらめて）sar コマンド*1を使うことになった。で、ついでにメモをしておこうかと。 例えば、1秒おきのCPUの情報（-u オプション）を、時間制限なくログファイルに残す場合には、次のように実行する（クーロンで定期実行されているかもしれないが、一時的に取得間隔を短くしたい場合など）。 # バイナリファイルに残す /usr/bin/sar 1 0 -u -o /log/sar_cpu > /dev/null 2>&1 & # テキストファイルに残す /usr/bin/sar 1 0 -u >> /log/sar_cpu.log & ここで、sarのman的には、インターバル 1 とカウント 0 はコマンドの最後に持っていくのだが、それだと -d オプションだけが（なぜか）動かないので、最初に持ってきている（これでなぜか動く）。どうした RHEL5
Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング
もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回DockerホストのTCPカーネルパラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、インスタンス数も削減できた上に安定してメシウマ状態になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つのケーススタディであることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストはUbuntu（EC2 Optimized AMIは未使用） Docker 1.11.2 MySQL（HAProxy経由）やRedisへのデータストアの通信、各microservicesへの
消すだけなのに rm -rf がいっつも長くて待ちきれない問題 - kuenishi's blog
rmコマンドで大量のファイルを削除しようとするとjournaldがめっちゃリソース持っていく件— bokko (@cubicdaiya) 2017年8月3日 今時のファイルシステムはみんなジャーナルもってて何かあったときにそこからリカバリする仕組みになってるので、当たり前といえばそうなんだけども。 （TODO: ここにファイルシステムのツリー＋ジャーナルのポンチ絵を手描きでも何でも描く） ご本尊のデータのツリーと何らかのWALを1セットで持っておくのはRDBだろうがファイルシステムだろうがそうは変わらない、で、削除についても並行制御をうまくやるために削除フラグをログに入れておいてあとで本尊のデータを整理するというのが基本的な設計になる。そこで私は立ち上がった（TL;DR: 特にオチとかはないです）。 rm -rf が遅いのは人類にとって損失ではないか。もっと速く完了するようにすれば、 rm
CPU使用率は間違っている | Yakst
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
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に起因する高負荷問題から、システムコールやカーネ
free(1)のtotalとかusedなどの各項目をカーネルの方から見てみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
free(1)は/proc/meminfoを読みに行くので、Linuxカーネルでどのような変数を見せているのかを調べてみます。カーネルのバージョンは4.5です。あ、swapのほうは今回は見ません。 最初に見るのはfs/proc/meminfo.cで、このファイルが/proc/meminfoに対する操作を定義しています。/proc/meminfoをopenする処理はmeminfo_proc_open()で、実際の処理はmeminfo_proc_show()が行います。 211 static int meminfo_proc_open(struct inode *inode, struct file *file) 212 { 213 return single_open(file, meminfo_proc_show, NULL); 214 } 215 216 static const str
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rmでファイル削除後にdf -hで容量が減らない時の対処(Linux) | EasyRamble
Loading...
Linuxでネットワーク帯域と速度をモニタリングするコマンド
http://www.nces.is.nagoya-u.ac.jp/NEXCESS/blog/index.php?catid=44&blogid=5
