サーバーが重かった原因について
ほとんど何も動いていないにもかかわらず、このサーバーのblogがもっさりとしていると思っていました。何でだろう?mysqlのメモリ使用率が高いので、それが原因かな?と思いつつtopを眺めていたところ、systemd-journalが時折高負荷になっているのが見えました。ls -ltr /var/logを何回か叩いているとmail.log、syslog、dovecot.logあたりが結構な頻度で更新されてました。
ログを開いてみてたら、postfixに対する攻撃を受けてたやつでした。iptablesで弾いたりはしていますが、うざいです。これまでの対策に追加してfail2banの設定を追加して、ひとまずは様子見です。
参考にしたurlは以下。
Related posts
pythonその4 環境周りとdjangoインストール
ファイルの先頭行に何を書くのか? 直接実行したい時は以下を書くと良い。 具体的には直接実行しないクラスを書いたファイルには不要。 デフォルトエンコーディングは書いておいた方が良さそう。 rubyでのrbenvみたいなのは? わたしゃさくらのvpsにubuntu 14.04.02 LTSを入れて学習中。 なのですが、既に以下の状態。ここから実行環境の切り替えとかできるんだろうか… rubyのrbenvみたいなのは、direnvかpyenvらしい。virtualenvはその前みたい。誰かその辺の歴史みたいなのとかまとめてくれんかな。direnvはpythonもrubyもまとめて面倒みまっせ的なものみたいだけど、既にrbenvは導入済だし、今回はpyenvでやってみることにする。他の人のやり方を見つつ、以前にrbenv入れたのをhistoryで推測しながら以下を実行した。 なお、参考にさせていただいたのは以下でございます m(. .)m Ubuntu 12.04でpyenvを利用して速攻でPython3.4 + Nginx + uWSGI + FlaskなWebアプリケーション実行環境を作る (Qiita) Ubuntuにpyenvを用いてpythn環境を構築しました。(たくのこWeb) /usr/binにインストールされているpythonは置いといて、version 3.4.3をインストール。インストール前にdjangoとversionの整合性は確認した。インストールにはそこそこ時間かかる。何やらWARNINGが出てるが、気にしないったら気にしない。 rubyでいうところのgem(パッケージ管理)はpipだそうだ。pipは実行環境を先ほどインストールした3.4.3に切り替えたら入ってた。なのでdjangoをインストール。公式にある通りコマンド打ってみる。
さくらのVPSのストレージ変更オプションでえらい目にあった
このサーバーとは別のサーバーでさくらのVPSを借りているのですが、一番安いプランだとディスク容量が25GBでして、使用量が90%を越えている状態でした。 一回500円払えばストレージが倍になるオプションがあったので、試してみました。 そしたらネットワークがつながらない事態に。 ネットワーク設定をしましたが復旧せず。多分設定ミスがあったんでしょうね。同じ内容とは思われるけど、事象が同じ人の書かれている通りにコマンドを打ったら接続できるようになりました。 午前1:30から始めて3時間ぐらいかかりました。本当はmattermostとかnextcloudのメンテをしようと思ってたのに・・・ sshもつながったし、matttermostのサービスを立ち上げようとしたらnginxが死んでました。よくよくみたらletsencryptがなくなってました。ufwもなくなってるし、どうなっとんねんでした。 letsencryptを再インストールしようにもDNSが動かなかったので、/etc/resolv.confにnameserver 8.8.8.8を追加してaptが動くようにして、letsencryptをインストールして、設定をして、結局朝の5時までかかりました。 どういう仕組でストレージを変更してるんでしょうね?OSの端々に影響が出るって、よく分からないです。 すごい苦労はしましたが、ストレージは元のパーティションをリサイズして倍にすることができて良かったです。
gunicornの設定
djangoで何か作って運用するための準備としてgunicornを使ってみた。 gunicorn トップページには簡単に動きまっせみたいなことを書いているが、3晩はかかった。仕事だとしたらば1日潰れたぐらい時間がかかった。 まずはvagrantで動いてるubuntu 14.04にインストール つづいてサンプルアプリの写経 ~/src/gunicorn/myapp/myapp.py 動かしてみると、おー動く。 でもブラウザからは動作はしない。vagrantのポートフォワードの設定をしてもダメ。webサーバ、うちの場合はnginxの設定も必要らしい。 gunicornのインストール | i2bsの日記 なんとなく真似てgunicornのグループを作成して、vagrantユーザを所属させてみたが、結局confの設定は正しく読めなかった。 nginxの設定もunixドメインソケットのupstreamの設定がキモっぽいがsite-available/defaultに書いてると、/var/log/nginx/error.logに以下のエラーが出てnginxが起動しない。 ググってみるとどうもバーチャルホストの設定が必要らしくconf.d/になんか書く必要があるとのこと。参考にさせてもらったサイトでもよくみるとそうなってたので、そのようにした。でもconf./dの設定とsites-availableの設定の関係性が分からなくなった。 confの設定がどうも効かないので、CLIから直接起動。アプリを書いたディレクトリで、以下を叩く。 今度はListeningのlogが変わった。 がしかし、http://127.0.0.1:18000/にアクセスすると、gunicornのアプリがエラーする。(18000はvagrantへのhttpアクセスのport forwardの設定port) “gunicorn type error not a byte”でググって、stackoverflowで解決。 gunicorn (Python3.4 and 3.3) sends in response only headers without data | stackoverflow 元のアプリがpython 3系だとダメらしい。以下のresponseとおぼしき1行を修正してブラウザからの動作は確認できた。 – return iter([data]) + return [bytes(data, ‘utf-8’)] 残すは設定ファイルからのgunicorn起動。 2015/10/05追記 設定ファイル書けた。たぶんファイルのパーミッションの問題で、daemon化ができていなかった。以下は動作が確認できたファイルで、logファイルは先に作成して、chmod 666した。 なお確認したソフトのバージョンは、以下。 python 3.4.3 nginx 1.4.6 gunicorn 19.3.0
Trackbacks and Pingbacks on this post
No trackbacks.
- TrackBack URL
Comments on this post