MySQL がちょいちょい落ちるので EC2 に swap 領域を設定

ちょいちょい MySQL が落ちるな~と思ってたんですが、swap 領域がないことが原因なのかもということで、swap 領域設定してみました。

メモリ確認

$ free
              total        used        free      shared  buff/cache   available
Mem:        1015348      423808      217400       46212      374140      400740
Swap:             0           0           0

Swap 0!

空き容量確認

$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   29G  4.2G   25G  15% /
devtmpfs                 487M     0  487M   0% /dev
...以下略

空ファイル作成

$ dd if=/dev/zero of=/swapfile bs=1M count=1024

swap 領域作成

$ mkswap /swapfile

権限変更

$ chmod 600 /swapfile

swap 領域有効化

$ wapon /swapfile

確認

$ swapon -s
Filename                                Type            Size    Used    Priority
/swapfile                               file    1048572 0       -1

$ free
Mem:        1015348      334316      279932       59680      401100      479768
Swap:       1048572           0     1048572

再起動しても swap が有効になるように

$ sudo vi /etc/fstab

で編集モードに入って、次の内容を末尾に追加

/swapfile   none    swap    sw    0   0

おわり。これで MySQL 落ちなくなるといいな~。

参考)

MySQL が起動しない原因がディスクフルだった

MySQL が起動しなくて、なんでだなんでだと調べたところサーバー容量が足りなかった、ということがありました。MySQL 起動しないのがディスクフルのせいだとは全然気づかなくて、しばらく journalctl -xn  してエラーログみたり色々してました。

珍しいケースだとは思いますが、MySQL 起動しなくて困った時は念のためサーバー空き容量を調べてみるといい、と勉強になりました。

未来の自分のために簡単に一応メモ。

CentOS7 でのサービスの起動・終了・再起動・状態

systemctl start 【サービス名】
systemctl stop 【サービス名】
systemctl restart 【サービス名】
systemctl status 【サービス名】

MySQL の状態を見たいなら次のようなかんじ。

systemctl status mysql

起動しない場合は、journalctl -xn  でエラーログを見る。

参考)CentOS7でのサービス(デーモン)の起動・停止方法 | server-memo.net

サーバー空き容量を調べる

$ df -h

Filesystem Size Used Avail Use% マウント位置
などが表示される。

サーバーのディスク容量アップ

今回はさくらのクラウドだったので、仮想サーバと仮想ディスク – 「さくらのクラウド入門」(1) – さくらのナレッジ を参考にディスク容量をアップ。

MySQL が壊れてる

さらに MySQL のテーブルが壊れてしまってたので、phpMyAdmin から

  • 「オーバーヘッド」のあるところは「テーブルの最適化」
  • 「使用中」になったままで構造が壊れてたところは「テーブルの修復」

をしました。これでなんとか復活。

参考)MySQL のテーブルを修復 – STAFF_01 [KYS-LAB]

Git LFS を使っていてクローンが遅すぎる時

Git LFS を入れて大量の画像などを Git 管理にしている場合、clone が重くて重くてエラー連発したりして泣きそう、という状態になったので調べました。

git-lfs の処理を飛ばして後からダウンロードする

上記ページにあるように、clone 時に git-lfs の処理を飛ばして後から git-lfs のファイルをダウンロードすると良さそうでした。

具体的には次のような形で頭に GIT_LFS_SKIP_SMUDGE=1 を付けて git clone して、

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/○○/○○.git

git clone が終わったら git lfs fetch で確認し、

git lfs fetch

最後に git lfs pull で LFS 管理のファイルをダウンロード。

git lfs pull

常に LFS ファイルは別途管理する場合

上記ページを見ていたところ次のように書く例がありました。

# from your repository working directory:
$ git config filter.lfs.smudge "git-lfs smudge --skip %f"

これだと常に git-lfs の処理を飛ばす形になるみたいです。「ノート PC では容量の都合で LFS 管理のファイルはダウンロードしたくない」などの場合に便利かも。

サイズの大きいバイナリファイルを扱うための Git LFS 導入

大規模プロジェクトで画像がめちゃくちゃ多い時など、これまでは Git リポジトリが大きくなりすぎてしまうことから画像だけ Git 管理を諦めて Dropbox などで別途共有していました。

Git LFS の発表があった後、実際にいつから使えそうかなとチェックしてましたが 10 月 2 日に全ての GitHub で利用可能になったとのアナウンスがありました( Git Large File Storage v1.0 )ので、早速試してみました。

Git LFS とは

Git Large File Storage

Git LFS はオープンソースの Git エクステンションです。バイナリファイルは Git 管理に向いていませんが、Git LFS はそれを解決できます。

Git LFS は、リモートサーバーに指定したファイル(バイナリファイル)を格納して、Git リポジトリではテキスト・ポインタとしておくので Git リポジトリが重くて困る、ということが起きないというもの。

Git LFS で管理するファイルはコミットした際、次のようになります。(画像が丸ごとアップされるわけではなく、テキストでリポジトリには記録されてます。)

st02 “サイズの大きいバイナリファイルを扱うための Git LFS 導入” の続きを読む

Vagrant + VirtualBox + Ansinble で MT を使えるようにする ver2

Vagrant + VirtualBox + Ansinble で MT を使えるようにする を書きましたが、ちょっと内容を変えて手順が減るようにしてみました。

  • CGI を実行可能にする
  • Apache ドキュメントルートを共有フォルダに

上記の手順が不要になります。少し楽!

  1. Vagrant と VirtualBox をインストールする
  2. Vagrant に box を追加する
  3. Vagrant 用にフォルダ作成して init
  4. Vagrantfile を編集する
  5. Vagrant を起動する
  6. Ansible をインストール
  7. SSH 接続の設定をする
  8. Ansible の設定ファイルを編集
  9. Ansible の playbook を作る
  10. MT の設置

“Vagrant + VirtualBox + Ansinble で MT を使えるようにする ver2” の続きを読む