ぜんぶTIME_WAITのせいだ！ - Qiita
課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39
Googleの検索結果のサマリーが文字化け
Googleの検索結果サマリーが文字化け 【1.3円/時間】GMOインターネットのSSD「ConoHa VPS」 Googleで検索していると、検索結果のページタイトルやサマリーが文字化けしていることがあります。それも特定のサイトのみです。しかも、どういうわけか、以下のように「縺」「繝」「繧」という糸偏の漢字がかなりの頻度で出没します。 「」（元の文字列は「プライバシーポリシー」）のような感じです。 （参照）「縺」の検索結果 ※ 1,250,000件!!※ http://www.google.co.jp/search?q=%E7%B8%BA&hl=ja&lr=&c2coff=1&start=20&sa=N ※2006年5月24日に検索した結果 （参照）「繝」の検索結果 ※1,900,000件 http://www.google.co.jp/search?q=%E7%B9%9D&hl
PostgreSQLのトラブルシュートとチューニング | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 笠原 辰仁 この記事は、gihyo.jp & Let's Postgres 連動企画「今こそ！PostgreSQL」の第6回記事です。第6回目は、PostgreSQLのエラーメッセージや内部情報を見て、発生している問題の特定とその対策となるチューニングを紹介します。なお、トラブルの発生・予兆を適切に捕捉するためにも、ログの設定や稼動統計情報の監視をしておきましょう。 エラーメッセージについて トラブルと対策の前にエラーメッセージのレベルについて説明しておきます。PostgreSQLは複数のエラーレベルを影響範囲や深刻度によって使い分けています。エラーレベルそれぞれの解釈の仕方を下記の表にまとめてみました。 データベース管理者は、深刻な状況である PANIC と、性能情報を含む LOG レベルのメッセージに注意しましょう。一方、アプリケーション開発者
パフォーマンス・ビューを使用したインスタンスのチューニング
この章の後半では、Oracleの動的パフォーマンス・ビューを使用したインスタンスのチューニングについて説明します。ただし、拡張機能リストによる統計の収集、監視およびチューニングには、自動ワークロード・リポジトリおよびAutomatic Database Diagnostic Monitorを使用することをお薦めします。「自動ワークロード・リポジトリの概要」および「Automatic Database Diagnostic Monitor」を参照してください。 問題の定義 ソリューションの実装を試みる前に、チューニング調査の目的と問題の性質をよく理解しておくことが不可欠です。これについて理解していないと、事実上、効果的な変更は実装できません。この段階で収集されたデータを使用して、次に行うこと、および調査する事象を簡単に決定できます。 次のデータを収集します。 パフォーマンスの目的を識別します
スレッドダンプの森で覚えた死のロックへの違和感
スレッドダンプの森で覚えた死のロックへの違和感：現場から学ぶWebアプリ開発のトラブルハック（11）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） スレッドダンプはトラブルハックに非常に有効 Javaを用いたシステムで発生したトラブルを解析する際、スレッドダンプは非常に有効な手掛かりを指し示してくれる。 例えば、連載第3回の「【実録ドキュメント】そのログ本当に必要ですか？」ではログ出力がボトルネックとなったトラブルを、解析ツールを用いたスレッドダンプ解析により発見している。また、連載第10回の「ThreadとHashMapに潜む無限回廊は実に面白い？」では、レースコンディション（競合
ORA-28000 the account is locked – あんじーのテクニカルブログ
ソフトウエア開発技術者(2004) テクニカルエンジニア(ネットワーク)(2006) ネットワークスペシャリスト(2012) 情報セキュリティアドミニストレータ(2008) データベーススペシャリスト(2010) LPIC Level3 Security(LinuC Level-3 Certification 303 Security)(2015) ORACLE MASTER Oracle Database 11g Bronze(2011) プロジェクトマネージャ(2014) 日商簿記２級(2015) 2級FP技能士(2016) ITサービスマネージャ(2016) Hinemos認定アソシエイト (監視）/Hinemos認定アソシエイト （ジョブ）(2018) カテゴリー FP (2) LPIC/LinuC (30) LinuC1(101) (12) LinuC1(102) (3) Lin
最強チームで挑んだ、「40時間でデータ移行」の壁
最強チームで挑んだ、「40時間でデータ移行」の壁：システム開発プロジェクトの現場から（13）（2/2 ページ） 第1回移行リハーサルスタートと事件発生 移行プログラムの性能テストでも問題がないことが実証でき、いよいよ第1回移行リハーサルがスタートしました。移行リハーサルのメンバーは、サブリーダー4人と私。 テープデバイスからデータを新システムのサーバにロードし、いざスタート！……したのですが、最初の大きなテーブルの移行処理時に、まさかの事態が起きました。性能検証時の1秒間当たりの処理件数は200件ほどだったのですが、何と40件／秒という、いままで見たことのない劣悪なスループットを出していたのです。 サブリーダー Aさん 「う、うーん。何ですかね？ この遅さ……」 私 「……もうじき速くなるんじゃないかな。取りあえず昼飯にでも行くか」 若干思考が停止気味だった私とサブリーダーのうちの1人は
障害対応とチューニングの危うい関係
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 パフォーマンス・チューニング・チームのリーダーに 前回「オフショアなんて、怖くない」では、オフショアでの開発を含む大規模基幹システム構築プロジェクトの経験を基に、私がオフショア開発に思うことをお話ししました。今回はその続きで、同じプロジェクトでのパフォーマンス・チューニングについてです。 オフショアでの開発・結合テストも終了し、システムテストが開始されました。移行のリハーサルも無事完了し、数百万件のトランザクションが投入されました……。と、ここまでは順調に見えましたが、移行データでのテストを開始してすぐに、性能に関する問題が表面化しました。 数百件、数千件のテストデータでは問題なく動いていたアプリケーションが、ボタンを押しても数分間応答しなくなったり
ThreadとHashMapに潜む無限回廊は実に面白い？ (1/3) - ＠IT
ThreadとHashMapに潜む無限回廊は実に面白い？：現場から学ぶWebアプリ開発のトラブルハック（10）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） マルチスレッドのトラブルハックはさっぱり分からない… 対処が難しいトラブルといえば、GC（ガベージ・コレクション）とマルチスレッド処理に起因することが多い。 前々回（「肥え続けるTomcatと胃を痛めるトラブルハッカー 」）と前回（「JavaのGC頻度に惑わされた年末年始の苦いメモリ」）の2回にわたってGC、特にメモリ周りのトラブルを取り上げた。そこで今回は、マルチスレッド処理のトラブルの1つ、「レースコンディション（競合状態）
サービス直前の非常事態！ アプリケーションが復帰しない？
サービス直前の非常事態！ アプリケーションが復帰しない？：Linuxトラブルシューティング探偵団（2）（1/3 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を＠ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務
Java Database Connectivity (JDBC) - dbcp.BasicDataSource, Oracle and broken pipe
I'm using the BasicDataSource from apache commons dbcp in a struts application to connect to an oracle 8.1 dbs. If the dbs is restarted (what happens pretty rarely, but the app should run for months without restart) I'm getting a broken pipe SQLException. Apparently the BasicDataSource doesn't reconnect when needed. Other databases have some parameter like autoReconnect=true, but I haven't found
【真夏の夜のミステリー】Tomcatを殺したのは誰だ？
【真夏の夜のミステリー】Tomcatを殺したのは誰だ？：現場から学ぶWebアプリ開発のトラブルハック（6）（3/3 ページ） 【第6章】解決 原因が分かれば対処は簡単だ。今回のシステムでは、TomcatのmaxThreads値を350に変更した。 Apacheの全スレッド数より50多く設定した理由は、Apacheからの再接続が発生した際でも耐えられるよう、多少余裕を持つようにしたためである。どれくらい余裕を持てばよいかは、各システムの状況によって異なる。今回のシステムではこの設定変更以降、無応答となる事象は起こらなくなった。 ■負荷テストをしていたのに、なぜ問題が発見できなかったのか？ 今回のシステムでは冒頭で述べたとおり、試験環境で負荷試験を行っていた。それにもかかわらず、なぜこの問題が発見できなかったのか？ 実は、後から分かったことだが、負荷試験の際、APサーバの台数は本番環境と同じ2
Apacheのトラブルを解決する10のヒント - builder by ZDNet Japan
本当のデータ活用できていますか？ データドリブンがあたりまえと言われる今あらためて考えたいデータ活用のありかた これからの社内DX 真のDXのため、まずは社内のデジタル化を DXのファーストステップのヒント データ活用は次のステージへ トラディショナルからモダンへ進化するBI 未来への挑戦の成功はデータとともにある コマース広告の大変動 プライバシー保護とパーソナライズの狭間で マーケティングの効果を最大化するためには オープンソース活用はあたりまえ！ そんな今だからこそ改めて考える 企業ITにおけるOSS活用のメリットとリスク 仮想環境データ保護の新次元 高度化・複雑化するIT環境の課題への解決策 最新鋭データ保護・管理ソフトウェア基盤 最新ストレージで変わるIT運用 仮想化テクノロジーとFlashArrayの組合せで 運用負荷軽減と高性能化を実現したDMM 現場主導のデジタル変革 ビジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.qunea.com/blog/log/20070123-2224.html
Javaトラブルシューティングメルマガ総集編 2008/08～09