エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント1件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
[ThinkIT] 第3回:max_connectionsとthread_cacheのチューニングを行う (3/3)
先ほどまでとは違い、Max_used_connectionsは同時接続数の増加と共に増え、最終的には400近くになりまし... 先ほどまでとは違い、Max_used_connectionsは同時接続数の増加と共に増え、最終的には400近くになりました。また、Threads_createdが激減し、ほとんどスレッドが生成されなくなりました。 これがthread_cacheの直接的な効果ですが、それ以上に重要なのはスレッド生成の負荷がなくなったことによって、Queries_per_secが「同時接続数が増加してもばらつきが少なく、数値も低下しにくくなった」という効果があらわれていることです。 データのばらつきは多少あるものの、ひいき目に見れば「Max_used_connections=310程度まではQueries_per_secを維持している」といえるのではないでしょうか。先ほどは128でしたから、単純な数値の比較で約2.5倍の同時接続に耐えうるサーバになったのです。
2016/04/17 リンク