a tomato

トマトが大好きです

データベースに接続中のセッションを強制切断する方法

TIPS

データベースに関する設定を行う時に、接続中のユーザがいると操作が正常に行えない場合があります。 そんな場合の対処です。

f:id:kzdev:20170921125812p:plain

前提

Software Version
PostgreSQL 9.6.1

手順

postgres=# alter database xxxxdb rename to xxxxdb_org;
ERROR:  database "xxxxdb" is being accessed by other users
DETAIL:  There are 2 other sessions using the database.

この場合、接続中のユーザセッションを強制的に切断後に再実行します。
まずは、接続中のユーザのpidを以下のコマンドで求めます。

postgres=# SELECT pid FROM pg_stat_activity where pid <> pg_backend_pid();
  pid  
-------
 15725
 16586
(2 rows)

参考 PostgreSQL: Documentation: 9.6: System Administration Functions

上記のように2ユーザいるので、それぞれのpidを強制切断します。

SELECT pg_terminate_backend(15725);
 pg_terminate_backend 
----------------------
 t
(1 row)

SELECT pg_terminate_backend(16586);
 pg_terminate_backend 
----------------------
 t
(1 row)

これで再実行します。

postgres=# alter database xxxxdb rename to xxxxdb_org;
postgres=#

dockerコンテナの日本語対応(centos)

SERVER

dockerで公式centosイメージからコンテナを起動すると、時間とエンコードが日本語に対応していないので困った時の対策です。

f:id:kzdev:20170913005837p:plain

公式 www.docker.com

前提

Software Version
Docker 17.06.2-ce

手順

まずはcentosイメージをダウンロードします。

docker pull centos:latest
% docker images                                                                                                                                                                                          REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos              latest              328edcd84f1b        5 weeks ago         193MB
centos              6.8                 0cd976dc0a98        12 months ago       195MB

続いて、ダウンロードしたイメージでコンテナを起動します。

% docker run -i -t centos /bin/bash
[root@7f86c5aa58d6 /]#

無事にコンテナに入ったら、時間が正しいか確認してみます。

[root@7f86c5aa58d6 /]# date
Tue Sep 12 15:40:21 UTC 2017

はい。UTC(協定世界時)になっているので、JST-9時間ですね。
もう時刻やらタイマーを乱用するプログラムの試験などする場合は、この上なく困ります。

更に、localeなんかも日本語等の無駄なものはイメージ作成時に軽量化のため削除されてしまっているわけです。

[root@d8e528556ee7 /]# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

ですので、日本語化したcentosのイメージを新たに用意します。
イメージ生成用のDockerfileはこちら。

FROM centos:6.8 
MAINTAINER "kzdev" <xxxx@gmail.com>  

RUN yum -y update
RUN yum -y install epel-release 
RUN yum reinstall -y glibc-common
ENV LANG ja_JP.UTF-8 
ENV LANGUAGE ja_JP:ja
ENV LANGUAGE ja_JP:ja
RUN yum clean all

RUN echo 'ZONE="Asia/Tokyo"' > /etc/sysconfig/clock 
RUN rm -f /etc/localtime
RUN ln -fs /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

yum reinstall -y glibc-common で削除されたlocale達を復活させます。

続いて時刻設定を行います。
RUN echo 'ZONE="Asia/Tokyo"' > /etc/sysconfig/clockで、ハードウェアクロックのタイムゾーンをASIAに変更します。

次にシステムクロックの変更を以下で行います。 既に配置されている/etc/localtimeを削除して、同名でASIAのタイムゾーンファイルのシンボリックリンクを作成しています。

これでdocker imageをビルドします。

% docker build ./ -t centosj
...
Removing intermediate container dcb5ad3e340f
Step 12/12 : RUN ln -fs /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
 ---> Running in 6c66749583f5
 ---> 967ab0235536
Removing intermediate container 6c66749583f5
Successfully built 967ab0235536
Successfully tagged testdev:latest

と出たら成功です。

稼働確認

無事にイメージを作成できたので、コンテナを起動してきちんと日本語になっているか確認してみます。

% docker run -i -t centosj /bin/bash
[root@65d95e00003c /]# date
2017年  9月 13日 水曜日 01:11:32 JST
[root@65d95e00003c /]# locale
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

日本時間と日本語化が無事に確認できました。

まとめ

必要な環境や機能が出てきたら、Dockerfileに追記してイメージを作ってコンテナを上げて使うという繰り返しになります。 一度イメージを作ってしまえば、生成や破棄はすぐに出来るので、試験やちょっとした動作確認にはもってこいです。

必要な機能を搭載したイメージに関しては、ほとんどがdocker-hubに既に上がっているので、探してなかったら作るとかの方が時短にはなると思います。

https://hub.docker.com

golang1.9 ReuseRecordでCSVのREADパフォーマンスが向上するかも！？

PROGRAM

golangを1.9にアップデートしてみました。

Go 1.9 Release Notes - The Go Programming Language

f:id:kzdev:20170908010918p:plainf:id:kzdev:20170908010918p:plain

release noteを見ると機能の追加からパフォーマンスの向上まで色々ありますが、
今回は、CSVのREAD性能が向上したというので、ベンチマークを取ってどのくらい改善されたのか確認します。

続きを読む

MacにVisualStudioCodeを使ったpython開発環境の構築

TIPS

Mac上(macOS Sierra)にVisualStuioCodeをインストールして、pythonの開発環境を構築していきます。
pythonは2系と3系がありますが、今回は3系を利用します。

前提

  • homebrewが導入済みであること
  • VisualStudioCodeがインストール済みであること

code.visualstudio.com

インストール

terminalを起動し、以下の手順でpythonをインストールします。

% brew install python3

% which python3
/usr/local/bin/python3

% which pip3
/usr/local/bin/pip3

以下は、pip3でインストールすることに注意して下さい。

参考

qiita.com

% pip3 install virtualenv
% pip3 install virtualenvwrapper

virtualenvwrapperを使うために、以下の環境変数を追加します。

$ vim ~/.basrh

補足 zshを利用している場合は、~/.zshrcに追加して下さい。

export WORKON_HOME=~/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3

追加した環境変数を読み込みます。

$ source ~/.basrh

仮想環境の作成

virtualenvにより、システム側にインストールされたpython環境と切り離した環境を作る。

基本は、システム側に大量のpackageがインストールされてカオスになることを防ぐために、基本は案件毎に仮想環境を用意して開発した方が良いです。

% mkdir /Users/kzdev/python_env
% cd /Users/kzdev/python_env

# mkvirtualenv <option> <仮想環境の名前>
% mkvirtualenv --no-site-package venv1
    # --never-download        : ネットワークからDLをしない
    # --system-site-packages  : インストール済みモジュールを使用する
    # --no-site-packages      :  インストール済みモジュールを全て外した状態で仮想環境が作成される

# 作成された仮想環境がロードされた状態になる
(venv1)%

VisualStudioCode設定

  • Command + Shift + Pを押して、Command Paletteを起動
  • >shellと入力して、以下の画像赤枠の項目を選択実行する

f:id:kzdev:20170905033825j:plain

補足 上記の設定で、terminal上からcodeでVisualStudioCodeを起動することが出来る用になります。

  • Code-基本設定-設定を開き、以下の設定を追記する。
"python.pythonPath": "/Users/kzdev/python_env/venv1/bin/python"

VisualStudioCodeをterminal上から起動する。

(venv1)% code .

この状態で、仮想環境のpythonを使ってdebugが出来るようになります。
試しに、debug実行を試してみます。

f:id:kzdev:20170905035811j:plain

breakpointを指定して、プログラムを起動します。

f:id:kzdev:20170905035928j:plain

上記の通り、指定したbreakpointで停止していることが確認できました。
これでVisualStudioCodeを使ってpython開発ができるようになりました。

IntelliJ IDEAの動作が遅い時の対策

TIPS

普段は、InteliJ IDEAを使って開発しているのですが、メモリの初期設定が以下のようにかなり少ないです。
初期状態で開発を行うと、アプリケーションの規模によっては内部indexの作成に時間がかかりかなりストレスが溜まります。
開発のストレスを少しでも軽減するために、設定の変更で利用するリソースを適切に調整して対処を行います。

-Xms128m
-Xmx2048m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops

そこで、端末のメモリ状況に合わせて、ヒープサイズを増やします。
Intelijを起動して上部のHelpメニューないから下記の項目を開きます。

f:id:kzdev:20170903212246j:plain

すると以下のようなファイルがIntelij内で開かれます。

f:id:kzdev:20170903212401j:plain

ここの数値を今回は、以下のように変更します。

-Xms2G
-Xmx4G
-XX:+UseG1GC
-XX:-UseParNewGC
-XX:-UseConcMarkSweepGC
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
-XX:+OmitStackTraceInFastThrow
-Dsun.io.useCanonCaches=false

保存したら、InteliJを再起動して完了です。初期に比べて相当快適になりました。

参考

github.com

KEA-DHCPの構築

SERVER

ISC-DHCPからKEA-DHCPに移行した際にサーバ構築を行いましたので、 構築手順をまとめます。今回の移行に至った経緯と現状の懸念事項は、以下の通りです。

採用理由

  • データベースを使ったIPリース状況の管理が出来る
  • ISC-DHCPに比べて高速
  • JSONによる無停止での設定変更
  • 大手企業でも利用されている実績が増えてきていること

懸念事項

  • DHCPフェイルオーバに未対応(RFC3074相当)

参考

f:id:kzdev:20170902055015p:plain

続きを読む