DatadogエージェントのGUI画面

新しいDatadogエージェントのGUI画面はブラウザベースのものに置き換わりました。

GUIで使用するポートは、「datadog.yml」で設定します。
「port」に「-1」を指定すると、GUIが無効化します。
既定では、WindowsとMacではポート「5002」で有効になっていて、Linuxでは無効になっています。

Windowsでは、「ddtray」で「-launch-gui」フラグをつけて実行するとGUIを起動できます。
「ddtray」は、アプリケーションフォルダーのショートカット経由で起動できます。

「ddtray」は、システムトレイ機能を提供し、Webベースの設定GUIを起動、停止、Datadogサービスの再起動ができます。
システムトレイは、flareディレクトリで初期化されます。

必要条件

  1. Cookiesは必須です。
  2. GUIはユーザー権限が必要で、datadog.ymlを開けるユーザーであれば使用できます。
  3. セキュリティ的な理由で、ローカルネットワークインターフェイス(localhost / 127.0.0.1)からしかアクセスできません。

開発中

Restart Agent機能は、まだWindowsではないプラットフォームには実装されていません。

個人的メモ

技術資料

動画

書籍

SQL ServerインポートおよびエクスポートウィザードのSSISパッケージのオプションについて

SQL Server インポートおよびエクスポートウィザードでデータの移行ができます。画面でぽちぽちして、最後にSSISのパッケージとして保存することができます。
保存すると「.dtsx」という拡張子で出力されます。

ウィザードで出力されたSSISパッケージの細かいオプションがどうなっているのかが気になったので調べてみました。

前提:今回の調査では、コピー元もコピー先もSQL Server Native Clientで同じAzure SQL Databaseサーバーの別のデータベースにコピーしています。

制御フローは1つだけです。

image

制御フローにパラメーターで気になるのは次のところ。

  • AutoAdjustBufferSize:False
  • DefaultBufferMaxRows:10000
  • DefaultBufferSize:3145728
  • EngineThreads:10

SSISとしては、シンプルなデータフローが定義されています。

image

データソースはこんな感じです。

出力クエリとそれによって取得できるカラムの情報ですね。

image

image

コピー先の設定はこんな感じ。

image

テーブルロックされて、CHECK制約が有効で、IDは保持しなくて、NULLも保持しない。

データアクセスモードは、「テーブルまたはビュー 高速読み込み」

バッチごとの行数はブランクで、挿入コミットサイズの最大値は2147483647。

あとはデータのマッピング情報がありますね。

image

バッチサイズについて

参考:https://www.mssqltips.com/sqlservertip/1840/sql-server-integration-services-ssis-best-practices/

バッチごとの行数は既定では「-1」で、すべての受信業が単一のバッチとして扱われる。
この値を変更すると受信したすべての行を複数のバッチに分割できる。設定可能なのはバッチ内の最大行数までの整数値。

挿入コミットサイズの最大値の既定値の意味は、受信したすべての行が正常に完了すると一回コミットされることを意味するようです。
この値を変更しないと大量のデータ転送中にトランザクションログとtempdbの負荷が増大するという。

参考:MSDN ONLINE

参考:SSIS Best Practice

xdebug でリモートデバッグをするためのメモ

webdevops/php-nginx-dev を使用してDockerコンテナーで動かしたPHPをリモートデバッグできるようにするまでの過程。

    • webdevops/php-nginx-dev:7.2がdocker hub にpushされていない。でもGithub上にはDockerfileが作成されている。
      仕方ないのでgit clone して、docker buildして、docker pushして、それを利用することにした。
    • XDEBUG_REMOTE_CONNECT_BACKが有効になっていてphpstormと接続されない。
      Dockerfileで、「XDEBUG_REMOTE_CONNECT_BACK=0」として解決。
    • 悩んだらログを出してみる。php.iniに「xdebug.remote_log=”/tmp/xdebug_log”」を追記してログ確認
    • ポートがリッスンしているか確認する。「lsof -n -P -i :10000」。ポートは利用しているものに変更。デフォルトは9000
    • 設定を確認する。「php –info|grep debug」
    • xdebugがインストールされている確認する。「php -v」。
      インストールされていたら、「with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans」との表記がある。
    • ブレイクポイントが止まらない時は、ファイルマッピングできていないか、誤っている可能性がある。

Sequel Pro の動作が重くなった場合の解消方法

Sequel Pro が重くなったり、プチフリーズしたり、何か操作するたびにMacのカーソルがくるくるして、操作が快適にできないという問題が発生することがあります。

原因の一つとして、Sequel Pro は、「クエリの履歴」機能を持っており、実行したクエリを記録保持しています。
最近データの移行で手抜きをして数百万行のデータをSQL文としてコピーして、そのクエリを実行するということをしました。

結果、その数百万行のinsert文を読み込むので、Sequel Pro が非常に処理が遅くなるという事象につながりました。

「クエリの履歴」→「共用の履歴を削除」をクリックして履歴をクリアしたら、先ほどまでの処理遅さが嘘のように爆速快適になりました。

// Sequel Pro の削除、インストールとかをしたけど、しっかり消せてなくて、そのあたりの記録が残り続けていて解決しなかったという|ω・`)チラ