動かざることバグの如し

近づきたいよ 君の理想に

RubyでImageMagick使うにはMiniMagickの方がよい

画像処理の王者ことImageMagickrubyImageMagickを扱うには、RMagick一択だと思っていたが、最近だとMiniMagickというのもあるらしい

MiniMagickのメリット

  • メンテナンスがRMagickより盛ん
  • 書き方がRMagickより直感的(主観
  • メモリの使用量が少ないらしい

本家githubより

I was using RMagick and loving it, but it was eating up huge amounts of memory. Even a simple script would use over 100MB of RAM.

とのこと

試してみる

環境

Gemfileに

gem "mini_magick"

して

require 'mini_magick'
image = MiniMagick::Image.open("test.jpg")
image.resize "200x200"
image.write "test_converted.jpg"

しても

MiniMagick::Invalid: `identify /var/folders/6z/xq_8ddx97hq9hzlgwzjjdjbw0000gn/T/mini_magick20180117-38453-17ka2ql.jpg` failed with error:
identify: unable to load module `/usr/local/Cellar/imagemagick/6.9.6-2/lib/ImageMagick//modules-Q16/coders/jpeg.la': file not found @ error/module.c/OpenModule/1302.
identify: no decode delegate for this image format `JPEG' @ error/constitute.c/ReadImage/504.

とエラーが

解決策

なんでやねんbrew install imagemagickちゃんとしたわと思っていたが、どうもtiff対応のimagemagickでないとダメらしい

ってことで一旦アンインストール

$ brew uninstall imagemagick

libtiff対応のimagemagickインストール

$ brew install libtiff
$ brew install imagemagick --with-libtiff

確認

$ convert -version
Version: ImageMagick 7.0.7-21 Q16 x86_64 2018-01-08 http://www.imagemagick.org
Copyright: © 1999-2018 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules 
Delegates (built-in): bzlib freetype jng jpeg ltdl lzma png tiff xml zlib

参考リンク

Gitlabを8から10にアップデートする

gitlabのオープンソース版の方を8.9.1から10.1 にアップデートさせた手順メモ

環境

  • CentOS 6
  • omnibus-gitlab経由でインストールされた

アップデートの流れ

マイナーバージョンのアップデートであればyum install gitlab-ceすれば勝手に新しいパッケージがインストールされる。

が、今回のようにメジャーバージョンが変わるようだと公式アップデートドキュメントを参考に慎重に行う必要がある。

手順

今回だと10に上げるにあたってsudo gitlab-ctl pg-upgradeしろと書いてあるが実行してもコマンドがないと怒られる。

# gitlab-ctl pg-upgrade
I don’t know that command.

は?????と思って調べると、pg-upgradeコマンドが実装されたのが8.9.16で、現行のgitlabには無い事が判明。

段階的にアップデートするしかないので、まずは8.9.16に上げる。

# wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/6/gitlab-ce-8.16.0-ce.0.el6.x86_64.rpm/download -O gitlab-ce-8.16.0-ce.0.el6.x86_64.rpm
# rpm -Uvh gitlab-ce-*.rpm

で、

最後に

yum install gitlab-ce-10.0.7-ce.0.el6.x86_64

すればおk!

アプデ前は gitlab-rake gitlab:backup:createでバックアップを忘れずに

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driverで死ぬ

環境

  • gcp Ubuntu 16.04
  • Tesla k80
  • CUDA 8.0
    • CUDA 9でもダメだった

突然CUDAが使えなくなる

ある日pythonからGPUが使えない事態に。やれやれと思ってnvidia-smiしても

# nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

は????????????同じ環境でつい3日前まで使えてたじゃん??????????謎の半導体メーカーNVIDIAの陰謀ってやつなのか????????

原因

Ubuntu側が提供している最新のLinuxカーネルにアップデートするとCUDAが動かなくなる

解決策

つまり以前のLinuxカーネルのバージョンに戻すしかない。今回は

  • 最新:4.13.0-1006
  • 旧:4.10.0-1004

だったので

旧バージョンのカーネルをインストール

# apt install linux-cloud-tools-4.10.0-1004-gcp linux-gcp-cloud-tools-4.10.0-1004 linux-gcp-headers-4.10.0-1004 linux-gcp-tools-4.10.0-1004 linux-headers-4.10.0-1004-gcp linux-image-4.10.0-1004-gcp linux-image-extra-4.10.0-1004-gcp linux-tools-4.10.0-1004-gcp

最新を一旦削除

# apt remove linux-gcp-headers-4.13.0-1006 linux-headers-4.13.0-1006-gcp linux-image-4.13.0-1006-gcp

GRUBの更新

# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.10.0-1004-gcp
Found initrd image: /boot/initrd.img-4.10.0-1004-gcp
done

で、再起動 uname- aでバージョンが古くなっていればおk

以前のバージョンとかはapt list|grep gcpとかで調べた

ふぁきんNVIDIA案件だわ

Vagrantのディスク容量を増やす

環境

  • vagrant 2
    • 以前のバージョンでも同様にいける
  • 使用したbox: bento/ubuntu-16.04

仮想ハードディスクの拡張

まずはゲストOS側(仮想側)で確認。デフォルトだと38GがMAXである。(/dev/mapper/vagrant--vg-rootの項目)ログとか貯まるとすぐに溢れそう

vagrant@vagrant:~$ df -h
Filesystem                    Size  Used Avail Use% Mounted on
udev                          465M     0  465M   0% /dev
tmpfs                          97M  3.1M   94M   4% /run
/dev/mapper/vagrant--vg-root   38G  1.4G   35G   4% /
tmpfs                         485M     0  485M   0% /dev/shm
tmpfs                         5.0M     0  5.0M   0% /run/lock
tmpfs                         485M     0  485M   0% /sys/fs/cgroup
/dev/sda1                     472M   57M  391M  13% /boot
vagrant                       4.3T  852G  3.5T  20% /vagrant
tmpfs                          97M     0   97M   0% /run/user/1000

ゲストOSをシャットダウンしてホスト側で作業開始。ゲストOSのディスクを拡張したいが、なんとvmdk形式では拡張できないクソ仕様なので、まずはVBoxManageコマンドでvdi形式に変換する。

$ VBoxManage clonehd ubuntu-16.04-amd64-disk001.vmdk tmp-disk.vdi --format vdi
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'vdi'. UUID: b84593dc-3ba3-4d2c-9151-b6d80f3bbc7c

でリサイズ。100GBにしたい場合は--resize 100000

$ VBoxManage modifyhd tmp-disk.vdi --resize 100000
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

変換が終わったら再びvmdk形式に戻す。--variant Fixedをつけると固定サイズになって容量は喰うがゲストOSのパフォーマンスは上がる。

$ VBoxManage clonehd tmp-disk.vdi ubuntu-16.04-amd64-disk001_resized.vmdk --format vdi --variant Fixed
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'vdi'. UUID: 5a3db394-a983-480c-82a2-ac07db2be84b

変換後に表示されたUUIDは後で使うので控えておく(ここでは5a3db394-a983-480c-82a2-ac07db2be84bを指す)

ディスクの入れ替え

次に拡張したディスクを拡張前のディスクと入れ替える作業。まずは対象ゲストOSのUUIDを調べる

$ VBoxManage list vms

ここではUUID=ccbee66b-ff49-4676-a6ba-f2e7e8904d74とする。

ディスクを外して、

$ VBoxManage storageattach ccbee66b-ff49-4676-a6ba-f2e7e8904d74 --storagectl 'SATA Controller' --port 0 --device 0 --type hdd --medium none

つける

$ VBoxManage storageattach ccbee66b-ff49-4676-a6ba-f2e7e8904d74 --storagectl 'SATA Controller' --port 0 --device 0 --type hdd --medium 5a3db394-a983-480c-82a2-ac07db2be84b

これでvagrant upできればおk

パーティションの拡張

なんとdfしてもまだ38GBのまま。。。これでオシマイ!ではなく、ゲストOS側でパーティションの拡張作業が必要

fdiskをつかってまずは既存のパーティションを削除する

# fdisk /dev/sda

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

pでまずは現状のパーティションを表示

Command (m for help): p
Disk /dev/sda: 97.7 GiB, 104857600000 bytes, 204800000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe0816098

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1  *       2048   999423   997376  487M 83 Linux
/dev/sda2       1001470 83884031 82882562 39.5G  5 Extended
/dev/sda5       1001472 83884031 82882560 39.5G 8e Linux LVM

ここでは/dev/sda2を削除

Command (m for help): d
Partition number (1,2,5, default 5): 2

Partition 2 has been deleted.

再度表示/dev/sda2にぶら下がっていた/dev/sda5も消えてくれている

Command (m for help): p
Disk /dev/sda: 97.7 GiB, 104857600000 bytes, 204800000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe0816098

Device     Boot Start    End Sectors  Size Id Type
/dev/sda1  *     2048 999423  997376  487M 83 Linux

新しいパーティションで/dev/sda2を作成 First sector、Last sectorはエンターキーを押すだけで勝手に最大化してくれる

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): e
Partition number (2-4, default 2): 
First sector (999424-204799999, default 999424): 
Last sector, +sectors or +size{K,M,G,T,P} (999424-204799999, default 204799999): 

Created a new partition 2 of type 'Extended' and of size 97.2 GiB.

/dev/sda5も同様に

Command (m for help): n   
All space for primary partitions is in use.
Adding logical partition 5
First sector (1001472-204799999, default 1001472): 
Last sector, +sectors or +size{K,M,G,T,P} (1001472-204799999, default 204799999): 

Created a new partition 5 of type 'Linux' and of size 97.2 GiB.

確認 ちゃんと元あったパーティションが拡張されている

Command (m for help): p
Disk /dev/sda: 97.7 GiB, 104857600000 bytes, 204800000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe0816098

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sda1  *       2048    999423    997376  487M 83 Linux
/dev/sda2        999424 204799999 203800576 97.2G  5 Extended
/dev/sda5       1001472 204799999 203798528 97.2G 83 Linux

wで書き込み

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

再起動するのでホストOS側でvagrant reloadする

LVMの拡張

なんとこれでもまだ作業は終わっていなく、パーティションレベルの次はLVMレベルでの拡張が必要になる

PVの拡張

root@vagrant:~# pvresize /dev/sda5
  Physical volume "/dev/sda5" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

LVを最大化!

root@vagrant:~# lvextend -l +100%FREE /dev/mapper/vagrant--vg-root
  Size of logical volume vagrant-vg/root changed from 38.52 GiB (9861 extents) to 96.18 GiB (24621 extents).
  Logical volume root successfully resized.

resize2fsを最後に実行!

root@vagrant:~# resize2fs /dev/mapper/vagrant--vg-root
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mapper/vagrant--vg-root is mounted on /; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 7
The filesystem on /dev/mapper/vagrant--vg-root is now 25211904 (4k) blocks long.

確認。/dev/mapper/vagrant--vg-rootがたしかに95GBに増えている。

root@vagrant:~# df -h
Filesystem                    Size  Used Avail Use% Mounted on
udev                          465M     0  465M   0% /dev
tmpfs                          97M  3.1M   94M   4% /run
/dev/mapper/vagrant--vg-root   95G  1.4G   89G   2% /
tmpfs                         485M     0  485M   0% /dev/shm
tmpfs                         5.0M     0  5.0M   0% /run/lock
tmpfs                         485M     0  485M   0% /sys/fs/cgroup
/dev/sda1                     472M   57M  391M  13% /boot
vagrant                       4.3T  952G  3.4T  22% /vagrant
tmpfs                          97M     0   97M   0% /run/user/1000

やったね!

TensorFlowからGPUが認識できているかを2行コードで確認する

GPUのドライバ入れた!CUDAもOK!けどTensorFlowでちゃんと使えてるかわからん!ってときの確認用

環境

方法

from tensorflow.python.client import device_lib
device_lib.list_local_devices()

を実行してdevice_type:GPUのやつがあれば認識してる。

実際にやってみると、

$ python
>>> from tensorflow.python.client import device_lib
  return f(*args, **kwds)
>>> device_lib.list_local_devices()
2018-01-12 20:09:07.451631: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:892] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2018-01-12 20:09:07.452057: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1030] Found device 0 with properties: 
name: Tesla K80 major: 3 minor: 7 memoryClockRate(GHz): 0.8235
pciBusID: 0000:00:04.0
totalMemory: 11.17GiB freeMemory: 11.10GiB
2018-01-12 20:09:07.452093: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: Tesla K80, pci bus id: 0000:00:04.0, compute capability: 3.7)
[name: "/device:CPU:0"
device_type: "CPU"
memory_limit: 268435456
locality {
}
incarnation: 2319180638018740093
, name: "/device:GPU:0"
device_type: "GPU"
memory_limit: 11324325888
locality {
  bus_id: 1
}
incarnation: 13854674477442207273
physical_device_desc: "device: 0, name: Tesla K80, pci bus id: 0000:00:04.0, compute capability: 3.7"
]

って感じ

認識できてない場合(GPUとTensorFlowとの連携がうまく行ってない場合)だと以下のようにCPUだけになる。

>>> device_lib.list_local_devices()
[name: "/device:CPU:0"
device_type: "CPU"
memory_limit: 268435456
locality {
}
incarnation: 2286130473433412332
]

ちなみに自分の場合は pip install tensorflow-gpu が足りなかった