個人的メモ

技術資料

動画

書籍

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

webpack のビルド性能を95%改善した方法(Boxの事例)

Box のエンジニアブログに「How we improved webpack build performance by 95%」という記事が投稿されました。
Box では、それまで3時間21分かかっていたビルド時間を9分に短縮させました。

  • シングルCPU
    • babel-loader でキャッシュを有効にして26%の性能改善
    • キャッシュを有効にして、 uglifyjs-webpack-plugin v1 で並列処理をして45%の性能改善
    • webpack.config.js から設定一覧をエクスポートしないようにして28%の性能改善
  • 10CPU
    • node.js Child Process API を使用して67%の性能改善

ビルドマシンにメモリ制限がある場合、webpack.config.js で設定一覧をエクスポートしない

Webpackはwebpack.config.js から複数の設定をarrayとしてエクスポートできます。
同時に25言語の bundle をビルドするのに、一つのロケールにつき1つで25設定のarrayをエクスポートするのに、この機能にメリットを感じていました。
小さな設定のみの場合はとても便利な機能なのですが、boxの場合は、ビルドプロセスにメモリと時間を非常に使います。
初期設定で、 –max_old_space_size (memory limit) のnodeプロセスでwebpackを実行するのに4GBにしていましたが、倍の8GBにしたら性能が50%改善し、ビルド時間が3.35時間から1.7時間に減りました。

同じメモリ制限では、各設定でwebpackを実行するように設定を変更すると、同時に複数の設定を処理する場合と比較して、パフォーマンスが約28%向上しました。

babel-loader でキャッシュを有効にする

babel-loader キャッシュは、cacheDirectoryオプションで簡単に有効にできます。

loader: 'babel-loader?cacheDirectory'

デフォルトでは、node_modules/.cache/babel-loaderに、babel-loaderキャッシュ結果が格納されます。
babel-loader キャッシュを有効にした後、ビルド性能が26%改善したました。

新しい uglifyjs-webpack-plugin v1 は大きな違いをもたらします

すでにwebpack 3で提供されている UglifyJSプラグイン(webpack.optimize.UglifyJsPlugin) を使用しているかもしれません。

新しいuglifyjs-webpack-plugin v1を使用して、 UglifyJS v3 で使用してwebpack 4で計画されています。
新しい機能は、複数プロセスで並列処理に対応し、キャッシュを活用しビルド性能を45%改善します。

現時点で、webpack 3で、 uglifyjs-webpack-plugin v1 を使用するためには、

  • devDependenciesに、「”uglifyjs-webpack-plugin”: “1.0.1”」を追加する
  • webpackから「-p」フラグを消し、「uglifyjs-webpack-plugin v0.4.6」が呼ばれないようにする

キャッシュと並列オプションをプラグインに追加します。

new UglifyJsPlugin({
   cache: true,
   parallel: true
})

マルチコアビルドのメリット

ビルドマシンが複数CPUを持っている場合、 node.js Cluster と Child Process API 、または worcker-fram を使用することでwebpackビルドにメリットがあります。並列に処理される9つのWebpack構成を有効にすることで、25の構成すべてをビルド性能が
67%改善しました。