Pinbaを使用してPHPコードのパフォーマンスを監視する

たとえば、PHPやPythonを使用して、人気を博している典型的なスタートアップを想像してみましょう。 最初は、すべてが1つのサーバー（PHP（またはPython）、Apache、MySQL）上にあります。 次に、MySQLを別のサーバーに移動し、nginxをインストールしてコンテンツを配信します。キャッシュ用にmemcachedを追加し、さらにいくつかのアプリケーションサーバーを追加します。



時間が経つにつれて、サーバーの数が増加し、遅かれ早かれあなたは疑問に思うでしょう

「現在システムで何が起こっているのですか？」 このスクリプトまたはそのスクリプトはどのくらいの頻度で実行されますか？ 最も時間がかかる操作は何ですか？” Zabbixタイプの監視システムは、アプリケーションの状態の一般的な表面的な画像のみを提供します。



これらの質問に対する回答を得るために、Badbaはリアルタイムの監視および統計サービスPinbaを開発しました。 この記事では、システムの監視とプロファイリングに使用した経験について説明します。

Badooについて一言

タスクの難易度を評価するために、Badooがどのようなものかを簡単に説明します。 現在、2つのデータセンターがあり、1つはアメリカに、もう1つはヨーロッパにあります。 何百ものPHPサーバー、MySQLサーバー、C / C ++で書かれた数十のmemcachedおよび「自己作成」サービスがデータセンターにインストールされています。 Badooには独自のサブプロジェクト（たとえば、Webサイト、モバイルデバイスとデスクトップ用のアプリケーション）があり、実装と負荷の性質は大きく異なります。 1つのPHPリクエストで、多数の異なるデータソース（データベース、キャッシュ、サービス）とのやり取りが発生する可能性があります。 これはパフォーマンスには悪いですが、ビジネスタスクの解決には必要です。 また、これに加えて、新しいコードを週に2〜5回投稿します。 このようなシステムのパフォーマンスを監視することは簡単な作業ではありません。 ピンバは、PHPスクリプトのパフォーマンスの監視に関連する問題の大きな層の解決を支援しました。 このサービスは、処理されたすべてのPHPリクエストに関する情報を収集し、このデータに関する詳細なレポートを生成します。

仕組み

Habrahabrには、Pinbaでの作業を開始する方法に関する記事が既にありました。「 Pinba-PHPをリアルタイムで監視する 」。 その中で、著者はPinbaのインストール方法と構成方法を説明したので、今度はもっと興味深いことに集中します。



Pinbaを使用する一般的なスキームを図に示します。







ピンバは、PHPモジュール（英語のPHP拡張機能 ）とサーバーで構成されています。 Pinbaモジュールは、処理されたすべてのリクエストに関するデータをサーバーに自動的に送信します。 ピンバサーバーは、Cで記述されたサービスです。

• UDP経由で処理された要求に関するデータを収集します。
• このすべてのデータをメモリに保存し、レポートを作成します。
• MySQLプロトコルを使用して生データとレポートへのアクセスを提供します。つまり、実際にはMySQLエンジンです。

現在システムで何が起こっているのかを知るには、MySQLクライアントを使用してサーバーに接続し、レポートテーブルからいくつかのクエリを実行します。 たとえば、各PHPスクリプト（Pinbaで最も使用されているレポートの1つ）のリクエストに関する統計を表示できます。

mysql> SELECT * FROM report_by_script_name;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下では、Pinbaでレポートを操作する方法について詳しく説明します。

PinbaのPHPモジュールの仕組み

Pinbaサービスの最初のバージョンの計画段階でさえ、PHPコードに変更を加えることなく、一般的な統計情報の収集を整理するというアイデアがすぐに思いつきました。 PHPモジュールの作成経験がある人は、後者が各リクエストの前（フェーズPHP_RINIT）および処理後（フェーズPHP_RSHUTDOWN）にいくつかのアクションを実行できることを知っています。 たとえば、PHP_RINITフェーズでは、モジュールは内部リソースを初期化でき、RSHUTDOWNではリソースを解放できます。 PinbaのPHPモジュールはこれらのフェーズの両方を使用します。 RINITでは、初期化され、RSHUTDOWNでは、要求の処理に費やされたリソースの数が計算され、すべてのデータがUDPパケットによってPinbaサーバーに送信されます。



UDPパケットをCに送信するのは十分に速いため、PinbaモジュールはPHPプロセスに余分な負荷を追加しません。 また、Pinbaはモジュールとして機能するため、インストールと構成を行うだけで十分です。PHPコードを変更することなく、すぐに、各スクリプトのリクエスト数、平均時間などのシステムのパラメーターを見つけることができます。などなど。



残念ながら、複雑なシステムがある場合、共通のパラメーターでは十分ではありません。

タイマー

最初は、Pinbaの最初のバージョンにはタイマーがありませんでした（Pinba v0.1と呼びましょう）。 このバージョンでは、特定のスクリプトが呼び出される頻度、平均応答時間、バイト単位の平均応答サイズなどがわかります。 MySQL、memcached、またはその他のサービスへのクエリの頻度を見つけることは不可能でした。 それほど重要ではないように思えるかもしれませんが、私たちのシステムでは、MySQLとmemcachedに加えて、C / C ++で書かれた多数のサービスがあります。



システムに問題が発生した場合（たとえば、何かが「スローダウン」し始めた場合）、Pinba v0.1は問題があることを示しましたが、それが何であるかをすぐに理解できるとは限りませんでした。 ほとんどの場合、このような状況では、PHPがクエリを実行したサービス（MySQL、memcachedなど）の1つが有罪でした。



そのような問題領域を迅速に見つける方法を学ぶために、ピンバの次のバージョンでタイマーが導入されました。



実際、mysql_connect / mysql_query / memcache_connect呼び出しなどの動作時間を測定し、この時間をPinbaサーバーに送信してタイマーレポートを作成することにしました。 擬似PHPコードでは、次のようになります。

 pinba_timer_start(array('type'=>'db::connect', 'host'=>'users.sql')); $conn = mysql_connect(...); pinba_timer_stop();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、mysql_connect呼び出しの実行時間を測定し、2つのタグをタイマーにアタッチします。これにより、後でレポートを作成できます。



すべてのタイマーは、すべてのデータとともにPinbaサーバーに送信され、そこにレポートテーブルが作成されます。 これにより、現在最も時間がかかっている操作を確認できます。 さらに、たとえば、数百のMySQLサーバーがあり、そのうちの1つだけが遅くなる場合、Pinbaは非常に柔軟なタイマーレポートスキームのおかげで同じ問題のサーバーを簡単に計算できます。

テーブルを使い始める

ピンバがアクセスできるテーブルのリストは次のとおりです。

 mysql> SHOW TABLES FROM pinba; +--------------------------------------+ | Tables_in_pinba | +--------------------------------------+ | info | | report_by_hostname | | report_by_hostname_and_script | | report_by_hostname_and_server | | report_by_hostname_server_and_script | | report_by_script_name | | report_by_server_and_script | | report_by_server_name | | report_by_status | | request | | tag | | timer | | timertag | +--------------------------------------+ 13 rows in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

従来、すべてのテーブルは、生データとレポートを含むテーブルの2種類に分類できます。

生データの4つのテーブルがあります：リクエスト、タグ、タイマー、タイマータグ。 これらのテーブルには、最後の数分間のスクリプト、タイマー、およびタグへの各呼び出しの記録が含まれています。 負荷の高いシステムでは、これらのテーブルには何百万ものレコードが含まれている可能性があるため、直接使用することはお勧めしません。 代わりに、システムパフォーマンスを分析するのに十分な有用なデータを含むレポートテーブルを使用することをお勧めします。

レポート表

Report_by_script_name-最も使用されるレポートの1つ。 各スクリプトが呼び出された頻度、実行にかかった平均時間、CPU使用率、それに起因するトラフィック量に関する情報が含まれています。

 mysql> DESC report_by_script_name; +------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+--------------+------+-----+---------+-------+ | req_count | int(11) | YES | | NULL | | | req_per_sec | float | YES | | NULL | | | req_time_total | float | YES | | NULL | | | req_time_percent | float | YES | | NULL | | | req_time_per_sec | float | YES | | NULL | | | ru_utime_total | float | YES | | NULL | | | ru_utime_percent | float | YES | | NULL | | | ru_utime_per_sec | float | YES | | NULL | | | ru_stime_total | float | YES | | NULL | | | ru_stime_percent | float | YES | | NULL | | | ru_stime_per_sec | float | YES | | NULL | | | traffic_total | float | YES | | NULL | | | traffic_percent | float | YES | | NULL | | | traffic_per_sec | float | YES | | NULL | | | script_name | varchar(128) | YES | | NULL | | +------------------+--------------+------+-----+---------+-------+ 15 rows in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

接尾辞_totalが付いたフィールドは、過去5分間のすべてのリクエストに対応する値の合計です。 つまり、たとえば、 req_time_totalは、過去5分間の対応するスクリプトのすべてのリクエストの実行時間の合計です。 また、 req_time_total / req_countは、スクリプトの平均実行時間です。 req_utime_ *およびreq_stime_ *フィールドは、それぞれユーザーモードおよびシステムモードでのCPU使用率を示します。



当社では、これらのデータに従って、特定のスクリプトに対するリクエスト数のグラフと、スクリプトによるCPU消費のグラフを作成します（グラフ1、2）。



図1





図表2。





Report_by_hostname ：このレポートは、特定のサーバーに送信されるリクエストの数を示します。 フィールドのリストはほとんど同じですが、script_nameフィールドの代わりに、ホスト名フィールドがテーブルに含まれています。

 mysql> DESC report_by_hostname; +------------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+-------------+------+-----+---------+-------+ | req_count | int(11) | YES | | NULL | | ......... | hostname | varchar(32) | YES | | NULL | | +------------------+-------------+------+-----+---------+-------+ 15 rows in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらく、hostname変数のHostヘッダーで渡されるドメインを見ると予想される人もいます。 しかし、実際にはホスト名は変数$ _ENV ['HOSTNAME']の内容であり、マシンの名前が含まれています。



このレポートの主な目的は、特定のサーバーへのリクエスト数に関する情報と、一部のサーバーへのリクエストが近隣サーバーより多いかどうかに関する情報を取得することです。



Report_by_server_name ：このレポートでは、データはリクエストが送信されたドメインごとにグループ化されます。 特定のドメインに送られるリクエストの数を示します。 テーブル構造は前の2つと同じですが、データのみがserver_nameフィールドでグループ化されています。



Report_by_status ：このレポートは、スクリプトが終了するHTTPステータスを表示するために使用されます。

 mysql> SELECT req_count, status FROM report_by_status; +-----------+--------+ | req_count | status | +-----------+--------+ | 540622 | 200 | | 2578 | 301 | | 21955 | 302 | | 296 | 403 | | 2090 | 404 | +-----------+--------+ 5 rows in set (0.14 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

レポートのステータスが500の場合、PHPコードのどこかに「致命的なエラー」があることを意味します。

タイマーとタグ

上記のレポートは、一般的なシステム分析に役立ちます。 しかし、より詳細な分析のために、タイマーとタグを使用します。



タイマーは、コードの実行時間です。 タイマーには複数のタグを添付できます。 タグにはキーと値があります。 たとえば、上記のタイマーコードでは、

 pinba_timer_start(array('group'=>'db::connect', 'host'=>'users.sql')); $conn = mysql_connect(...); pinba_timer_stop();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mysql_connect関数の実行時間を測定し、グループとホストの2つのタグを添付します。



デフォルトでは、Pinbaにはタイマーとタグに関するレポートはありませんが、非常に柔軟に作成できます。 以下では、Badooでこれがどのように行われるかを詳しく見ていきます。



まず、タイマーを使用して、MySQL、memcached、C / C ++で記述されたサービスなど、さまざまなデータソースへのリクエストに関する統計を取得します。 グループとホスト（ホストはデータベースまたはサービスのアドレス、グループはサービスの操作）の2つのタグを持つPinbaタイマーを使用して、そのようなすべてのリクエストを「ラップ」しました。



したがって、Pinbaに送信されるタグをシステムに実装した場合、いくつかのレポートを作成できます。 まず、すべてのタグ値に関する完全なレポートになります。 groupタグを使用した例では、この操作またはその操作が呼び出される頻度と、その操作にかかる時間（合計）に関するレポートを作成できます。 これを行うには、テーブルを作成します。

 CREATE TABLE `tag_info_group` ( `tag_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag_info:group'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テーブル名は任意であり、何にも影響しません。 フィールドの順序が例とまったく同じであり、ENGINEおよびCOMMENT = 'tag_info：group'の値であることが重要です。 コメント内のgroupは、レポートを作成するタグの名前です。 また、tag_infoはレポートの一種です（tag_reportもあります。これについては以下で説明します）。



テーブルを作成すると、Pinbaは自動的にデータの入力を開始します。 このレポートは次のようになります。

 mysql> SELECT * FROM tag_info_group ORDER BY timer_value; +--------------------+-----------+-------------+-----------+-------------+-------------+ | tag_value | req_count | req_per_sec | hit_count | hit_per_sec | timer_value | +--------------------+-----------+-------------+-----------+-------------+-------------+ | curl_request | 56216 | 281.08 | 56710 | 283.55 | 11977.3 | | memcache_get | 2563499 | 12817.5 | 11462991 | 57315 | 6823.04 | | hsc_connect | 2319186 | 11595.9 | 2870366 | 14351.8 | 6140.5 | | hsc_open_index | 2319158 | 11595.8 | 3285335 | 16426.7 | 5805.61 | | hsc_select | 2312567 | 11562.8 | 3158465 | 15792.3 | 5778.57 | | memcache_connect | 2563064 | 12815.3 | 4007451 | 20037.3 | 2389.65 | | memcache_set | 917102 | 4585.51 | 1616016 | 8080.08 | 1059.08 | | memcache_delete | 600720 | 3003.6 | 2451872 | 12259.4 | 785.702 | | scribe_receive | 382881 | 1914.41 | 975892 | 4879.46 | 382.522 | | hsc_update | 84877 | 424.385 | 85287 | 426.435 | 317.637 | | hsc_insert | 41564 | 207.82 | 41574 | 207.87 | 280.468 | | scribe_send | 382894 | 1914.47 | 975892 | 4879.46 | 174.156 | | memcache_increment | 60817 | 304.085 | 88734 | 443.67 | 30.9102 | | memcache_add | 14818 | 74.09 | 16281 | 81.405 | 4.71686 | | memcache_multi_get | 2543 | 12.715 | 2543 | 12.715 | 1.59621 | | hsc_delete | 4 | 0.02 | 9 | 0.045 | 0.003373 | +--------------------+-----------+-------------+-----------+-------------+-------------+ 16 rows in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、このレポートは、非常に遅いcurl_requestがあることを示しています。



tag_infoタイプのレポートは、システムでの使用の概要を示します。 特定の操作が呼び出される場所をより詳細に調べるには、同じレポートを作成する必要がありますが、スクリプトの名前でグループ化されます。 これを行うには、Pinbaでテーブルを作成します。

 CREATE TABLE `tag_report_group` ( `script_name` varchar(128) DEFAULT NULL, `tag_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag_report:group'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テーブル構造は、以前のtag_info_groupレポートと多くの点で似ています。 script_nameフィールドが表示され、COMMENTフィールドにtag_reportタイプのレポートを作成したことに注意してください。 このテーブルから、前のものと同じデータをすべて取得できますが、 script_nameでグループ化されます 。



特定のスクリプトで実行される操作を確認できます。

 mysql> SELECT tag_value, req_count, hit_count, timer_value, hit_count/req_count FROM tag_report_group WHERE script_name='/admin/messages/all.phtml' ORDER BY timer_value DESC; +--------------------+-----------+-----------+-------------+---------------------+ | tag_value | req_count | hit_count | timer_value | hit_count/req_count | +--------------------+-----------+-----------+-------------+---------------------+ | memcache_get | 107439 | 3227537 | 1060.68 | 30.0406 | | memcache_connect | 107439 | 887789 | 270.919 | 8.2632 | | scribe_receive | 107573 | 283478 | 68.9106 | 2.6352 | | memcache_set | 34339 | 153080 | 50.6079 | 4.4579 | | scribe_send | 107573 | 283478 | 39.7583 | 2.6352 | | memcache_delete | 18236 | 21306 | 4.54436 | 1.1683 | | curl_request | 15 | 15 | 0.514396 | 1.0000 | | memcache_decrement | 1250 | 1250 | 0.251141 | 1.0000 | | memcache_multi_get | 125 | 125 | 0.066473 | 1.0000 | | memcache_increment | 2 | 2 | 0.000336 | 1.0000 | +--------------------+-----------+-----------+-------------+---------------------+ 10 rows in set (0.03 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例は、 hit_countフィールドとreq_countフィールドの違いを示しています 。 Req_countは、指定されたtag_valueのタイマーが少なくとも1回呼び出されたHTTP要求の数です。 Hit_count-指定されたtag_valueのタイマーが呼び出された回数。



上記の例は、スクリプト/admin/messages/all.phtmlで、memcache_getが平均30回呼び出されることを示しています。 おそらくこれはプログラマーのエラーであり、ページを最適化する必要があります。



多数のデータベースサーバー、memcached、およびその他のサービスがある場合、1つのサーバーのみが「スローダウン」する場合があります。 そして、一般的な背景に対するその「抑制」は明らかではないかもしれません。 これらの目的のために、 serverという別のタグを作成しました。 そのために、一般レポートtag_info：serverを作成し、各ホストの一般統計を確認できます。 memcached統計のサンプルデータを次に示します。

 mysql> SELECT * FROM tag_info_server WHERE tag_value LIKE 'memcache%' ORDER BY timer_value; +------------------+-----------+-------------+-----------+-------------+-------------+ | tag_value | req_count | req_per_sec | hit_count | hit_per_sec | timer_value | +------------------+-----------+-------------+-----------+-------------+-------------+ | memcached7.mlan | 350702 | 1753.51 | 1767513 | 8837.57 | 781.644 | | memcached3.mlan | 336217 | 1681.08 | 1734430 | 8672.15 | 871.633 | | memcached1.mlan | 350082 | 1750.41 | 1823910 | 9119.55 | 883.52 | | memcached8.mlan | 357798 | 1788.99 | 1793808 | 8969.04 | 908.848 | | memcached10.mlan | 343287 | 1716.44 | 1757085 | 8785.42 | 909.042 | | memcached5.mlan | 398042 | 1990.21 | 1861729 | 9308.64 | 914.772 | | memcached4.mlan | 401584 | 2007.92 | 1877775 | 9388.88 | 937.53 | | memcached2.mlan | 459912 | 2299.56 | 2028406 | 10142 | 971.189 | | memcached6.mlan | 399768 | 1998.84 | 1912571 | 9562.86 | 975.094 | | memcached9.mlan | 425276 | 2126.38 | 1939575 | 9697.88 | 1008.29 | +------------------+-----------+-------------+-----------+-------------+-------------+ 10 rows in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ホストタグの一般的なレポートは、十分な情報を提供しません。 1つまたは別のホストでタイマーを呼び出す頻度を示しますが、実行された操作に関する情報はありません。 幸いなことに、Pinbaは2つのタグをグループ化してtag_infoやtag_reportなどのレポートを作成できます。

 CREATE TABLE `tag_info_group_server` ( `group_value` varchar(64) DEFAULT NULL, `server_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag2_info:group,server'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このレポートを使用すると、各ホストの操作に関する統計を取得できます。 たとえば、特定のホストでの操作の統計を表示できます。

 mysql> SELECT * FROM tag_info_group_server WHERE server_value = 'dbs101.mlan' ORDER BY timer_value; +-------------+--------------+-----------+-------------+-----------+-------------+-------------+ | group_value | server_value | req_count | req_per_sec | hit_count | hit_per_sec | timer_value | +-------------+--------------+-----------+-------------+-----------+-------------+-------------+ | db::replace | dbs101.mlan | 154 | 0.77 | 154 | 0.77 | 0.257526 | | db::delete | dbs101.mlan | 1340 | 6.7 | 1340 | 6.7 | 1.84398 | | db::begin | dbs101.mlan | 6437 | 32.185 | 6589 | 32.945 | 2.96375 | | db::commit | dbs101.mlan | 6437 | 32.185 | 6589 | 32.945 | 3.04067 | | db::insert | dbs101.mlan | 4674 | 23.37 | 11171 | 55.855 | 13.9457 | | db::update | dbs101.mlan | 6358 | 31.79 | 10399 | 51.995 | 18.197 | | db::connect | dbs101.mlan | 16826 | 84.13 | 16826 | 84.13 | 22.1383 | | db::select | dbs101.mlan | 14372 | 71.86 | 47106 | 235.53 | 180.235 | +-------------+--------------+-----------+-------------+-----------+-------------+-------------+ 8 rows in set (0.01 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかな理由から、ほとんどの時間を占めるのはSELECTです。



また、たとえば、異なるホストでの同じ操作の統計を比較できます。 memcache_connectの例：

 mysql> SELECT server_value, req_count, hit_count, timer_value FROM tag_info_group_server WHERE group_value='memcache_connect' ORDER BY timer_value; +------------------+-----------+-----------+-------------+ | server_value | req_count | hit_count | timer_value | +------------------+-----------+-----------+-------------+ | memcached1.mlan | 366138 | 365061 | 191.808 | | memcached3.mlan | 354688 | 353760 | 192.184 | | memcached10.mlan | 365358 | 364341 | 197.353 | | memcached8.mlan | 368912 | 367839 | 213.768 | | memcached7.mlan | 374160 | 373152 | 215.914 | | memcached5.mlan | 415444 | 414434 | 217.855 | | memcached4.mlan | 423394 | 422242 | 252.416 | | memcached2.mlan | 478949 | 477641 | 272.346 | | memcached6.mlan | 414088 | 413003 | 279.038 | | memcached9.mlan | 441589 | 440481 | 377.952 | +------------------+-----------+-----------+-------------+ 10 rows in set (0.01 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

tag2_reportタイプのレポートを作成することもできます。このレポートでは、2つのタグに関する情報がスクリプトごとに分類されます。

 CREATE TABLE `tag_report_group_server` ( `sc0ript_name` varchar(128) DEFAULT NULL, `tag1_value` varchar(64) DEFAULT NULL, `tag2_value` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag2_report:group,server'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この表が役立つ例を示します。 このシステムでは、すべてのユーザーが数百のMySQLサーバーに分散されています。 これはシャーディングと呼ばれます。 特定のタスクのための特定の中央MySQLサーバーもあります。 理論的には、すべてのWebスクリプトは「シャード」のみを照会し、中央データベースは照会しないでください。 「シャード」のホスト名は、dbs *またはdbb *で始まります。 このリクエストを使用して、他のMySQLサーバーに接続するスクリプトがあるかどうかを確認できます。

 mysql> SELECT * FROM tag_report_group_server WHERE tag1_value='db::connect' AND tag2_value NOT LIKE 'dbs%' AND tag2_value NOT LIKE 'dbb%';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どのスクリプトが中央データベースでクエリを実行するかを示します。

nginx +ピンバ

しかし、これだけでも十分ではありませんでした。 クライアントがHTTPリクエストを送信すると、後者はまずnginxに入り、次にPHPにプロキシします。 この時点でPHPプロセスがリクエストを受け入れて処理できない場合はどうなりますか？ たとえば、サーバーが過負荷になっている場合、またはネットワークの問題が原因で、nginxがphp-fpmプロセスに接続できませんか？ この場合、ユーザーにはエラーが表示されますが、PHPではエラーがわかりません（nginxログには記録されます）。



クライアントに返す応答（HTTPステータス）を把握するために、Pinba開発者のAnton Dovgalはnginxのモジュールを作成しました。 nginxのモジュールはPHPモジュールと同じように機能しますが、明らかな理由からタイマーはありません。 彼が作成する最も有用なレポートは、 report_by_script_and_statusおよびreport_by_statusです。

プロット

ピンバは最後の数分間のデータを保存します。 この時間は設定で変更できます 。 しかし、これはシステムのパフォーマンスが時間とともにどのように変化するかを監視したい場合には十分ではありません。 これを行うには、Pinbaレポートデータ（必ずしもすべてではない）を長期間保存し、グラフを作成する必要があります。 したがって、システムとその個々のスクリプトの負荷のダイナミクスを観察したり、PHPコードがデータベース、memcached、およびその他のデータソースをロードする方法を監視したりできます。



ピンバは、長期間にわたってデータをプロットおよび保存する方法を知りません。 このためには、個別のユーティリティを使用する必要があります。 ピンバを監視し、その値の一部に基づいてグラフを作成するようにZabbixを設定できます。 RRDtoolやGraphiteなどのリング（サイクリック）データベースを使用できます。 当社では、RRDtoolを使用しています。



RRDtoolは簡単に説明していません。 彼には多くのニュアンスがあり、チャート作成の好みは人によって異なるため、このトピックは別の記事に値します。 インターネットには、このユーティリティセットをゼロから始めるのに役立つ十分なガイドが既にあります。

結果

ピンバは私たちに何をくれましたか？ ほとんどのパフォーマンスの問題は、その実装前よりもずっと早く検出され始めました。 スクリプトがユーザーにより頻繁に要求されるようになった場合、ピンバで簡単に見つけることができます。 サービスの1つ（MySQL、memcachedなど）の動作が突然遅くなった場合、Pinbaの適切なレポートを使用すると、このサービスを簡単にローカライズできます。 また、リクエストの頻度が高いために「スローダウン」し始めた場合、Pinbaのおかげで、特定の問題サービスを頻繁にリクエストするスクリプトをローカライズできる場合があります。



新しいバージョンのコードをサーバーにアップロードした後、ピンバチャートを見ると非常に便利です。 システムの負荷がどのように変化したかを確認できます。 ただし、このためには、どのようなグラフが作成されるかを考えることが重要です。



ただし、サーバー全体の監視の代わりにPinbaを使用しないでください。 たとえば、Zabbixを使用して、すべてのサーバーのCPU、メモリ、ディスク、およびネットワークアクティビティの消費を監視します。 一方、RRDにはチャートを含むPinbaがあります。 これら2つのシステムのグラフを比較することにより、PHPリクエストの「コスト」を簡単に計算し、サーバーが1秒間に処理できるリクエストの数を見積もることができます。 そして、これにより、近い将来に新しいサーバーを購入する必要があるのか​​、コードを最適化する機会があるのか​​を計画できます。



PHPモジュールとは別に、Pinbaは決してPHPに関連付けられておらず、他の言語で書かれたシステムを監視するために使用できます。 GitHubには、既にPythonとRubyでPinbaを使用したプロジェクトがあります。



マキシムmax_m Matyukhin、開発者

バドゥー会社

便利なリンク

• オフィシャルピンバプロジェクトページ
• Pinba Engine development list — Google- Pinba
• Pinba Engine development list (in Russian) — Google- Pinba
• Pinba — php — Pinba
• RRDtool
• Graphite
• — wikipedia.org
• Nginx module for pinba
• Python WSGI middleware for pinba