サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大阪万博
www.riscascape.net
PHP7.1からPHP7.2にアップデートしたところDeprecatedが出ました。create_function関数が非推奨になったとのことなので早速修正します。 Simplicity2テーマのウィジェットがcreate_functionを使用しているのが原因 検証用WordPressは常にデバッグを有効化しているため、エラーが出るとサイトの上に色々と表示してくれます。今回はこんな感じで出てました。(本当は10行もあります。) ログをしっかり読んでみると、simplicity2テーマのウィジェット用コードがcreate_function関数を使っているのが原因のようです。 Deprecated: Function create_function() is deprecated in /var/www/html/wp-content/themes/simplicity2/lib/widge
長年利用していたESET NOD32の利用を止めました。Windows Defenderで十分、むしろメリットがあるのではないかと・・・ ESETのお節介に飽き飽きして・・・ ESETは軽くて高性能・高機能で愛用していました。ですが「SSL/TLSプロトコルフィルタリング」機能だけは邪魔です。これはSSL証明書が安易に発行できるようになり、httpsだから安全とは一概にいえなくなった現在では確かに大事な機能なのですが、これが有効だとSSL証明書がESET発行のものに勝手に差し替えられるんですよね。 この挙動はブラウザがHTTPSプロトコルを受け取る前にNOD32が受け取りデコードして中身を確認し、再度NOD32がHTTPS化してブラウザに渡すという挙動によるものです。最近のL7ファイアウオールが搭載している機能と同じ「悪意のない中間者攻撃」ってやつです。 そして癪に障ったのがこの挙動。一部
サーバのMuninがyum-cronで2.0.28-2にアップデートされましたが、その後からDynazoomが効かなくなりました。対処方法を忘れないようにメモしておきます。 MuninのDynazoomが動作しない 急にMuninのズーム機能(Dynazoom)が動作しなくなりました。具体的には画像の生成ができていない状態です。(※下図参照) とりまログ参照 まずはMuninのグラフデータ生成に関するログ(/var/log/munin/munin-cgi-graph.log)を確認してみます。 # tail -f /var/log/munin/munin-cgi-graph.log 'GPRINT:areceived:MAX:%6.2lf%s\j' \ 'CDEF:cforwarded=gforwarded' \ 'LINE2:gforwarded#0066B3:Forwarded ' \
remiレポジトリで導入したPHP7でも十分な高速化を実現できましたが、環境に合わせた最適化コンパイルを行えばさらに速くなるらしいので試してみました。 1.目的と前提条件 CentOS6で稼働しているWordPressをさらに高速化するためにPHP7をコンパイルします。 Apacheは2.2でMPMはPreforkを利用し、OpcacheとAPCu/APC互換モジュールを利用できるようにします。これはWordPressの001 Prime Strategy Translate AcceleratorプラグインをAPCuでで利用するためにはAPC互換モジュールも導入するがあるのですが、PHP7からAPCuと分離されたとのことなので別途導入する必要があるためです。 作業はすべてrootユーザで実施。事前に「yum remove php」でPHPを削除しておきます。 また色々と厄介なSELiin
遅くなったVPNサーバのレスポンスを少しでも改善すべく、MySQL5.6のパフォーマンス改善を目指してinnodb_file_formatをBarracudaに切り替えてみました。 1. my.cnfファイルにinnodb_file_formatの行を追加する my.cnfはmysqldを再起動しないと反映されませんが、とりあえず先に追加しておきます。 innodb_file_per_tableはBarracudaに変更するための必須設定ですが、InnoDBへ変更した際に設定済なのでこの場での説明はパスします。 # vi /etc/my.cnf [mysqld] innodb_file_per_table = 1 + innodb_file_format = Barracuda + innodb_file_format_max = Barracuda 2. オンラインで対応フォーマットをB
MySQLを5.6にアップデートしてからメモリ使用量が明らかに増えました。メモリが少ないサーバでは無駄なメモリの消費は死活問題です。パラメータを調整していくうちに色々わかったことをまとめてみます。 MySQL5.6の新機能がメモリを消費する MySQL5.1のコンフィグでMySQL5.6を起動するとメモリ使用量が跳ね上がります。 原因は2つ。1つはDBの低レベルモニタリングを行うパフォーマンススキーマがデフォルトで有効になったこと。もう1つはパフォーマンススキーマが有効かつtable_definition_cacheの値が801を超えると300MB以上メモリ消費が増えるバグがあること。 デフォルト有効なので対策をしないと下のグラフの7日のようになります。これに対してtable_definition_cache=400を追加してまずは解決しましたが、それでもアップデート前よりはまだ高い状態で
QNAPのNASはQTS4.0.5からSMB2を有効に出来るらしいのですが、私のTS-112(QTS4.2.0)のには設定項目が存在しません。SMB2.0の利用を諦めていましたがCLIでは専用のコマンドが用意されているという情報を見つけたので試してみます。 GUIでのSMBバージョン設定箇所 QNAPのナレッジによるとSMB2設定は「ネットワークサービス」>「Win/Mac/NFS」>「Microsoft ネットワーキング >「高度なオプション」にあるはずですが、TS-112には項目が存在しません。 CLIでのSMBバージョン確認方法 ですが、Telnet/SSHでTS-112に接続すればCLI上で設定可能です。 まずは現在有効なSMBバージョンを調べる「smb2status」をTS-112上で実行してみます。 # smb2status smbd (samba daemon) Versio
メモリ1GBなLinuxサーバでWordPressを稼働させるには、どの機能(サーバ)を利用しメモリを割り当てるのか取捨選択と割り当てバランスが重要です。稼働一年半のノウハウを結集した自サーバMySQLセッティングを紹介します。 サーバ要件・セッティング条件 サーバのメモリは1GB。OSはCentOS6系、サーバアプリはyumでインストール可能なもの、yumは外部レポジトリも利用して可能な限り最新バージョンを使用。スワップをなるべく発生させないようにメモリ使用率は60%程度に抑えます。 これらの要件で選定した2016/9時点のサーバアプリとバージョンは以下の通り。なお以前利用していたclamavは熟考の結果、今は利用していません。 ・CentOS6.8 ・Apache2.2-PreFork ・PHP7 ・MySQL5.6-InnoDB (MySQL5.7は検証時にWordPressが動作し
Zabbixはメモリ監視がMuninより苦手です。デフォルトのLinuxテンプレートはあまり役に立ちません。ここはひとつ気合いである程度まで再現してみましょう。 お手本となるMuninのMemoryグラフ まずはMuninのグラフを確認します。 この中でも重要と思われるapps ~ swap(塗りつぶしグラフ)をZabbixで再現します。というかZabbix2.Xは塗りつぶしグラフと線グラフの共存ができません。 これらの値は、基本的に/proc/meminfoの値を参照すれば取得できるのですが「apps」と「swap」は自分で計算する必要があります。そうなると/etc/zabbix/zabbix_agentd.confにUserParameterを1行追加するだけでは実現できませんので、スクリプトを作成する必要が出てきました。 Memory取得スクリプトを作成する appsとswapはmu
clamavのメモリ使用量に悩まされてはや11ヶ月。どうしたらオーバーコミットを抑えつつhttpdにメモリを確保できるのか試行錯誤していましたが、ついに解決しました。 clamavの悩み clamdのメモリ使用量は約300MB。このサーバのメモリは1GBなので300MBは大きいです。 # ps aux|grep clam root 29087 0.3 30.5 527936 311460 ? Ssl Nov08 6:56 clamd ウイルススキャンは「CentOSで自宅サーバー構築」を参考に1日1回cronでclamscanを実行していたのですが、スキャンの度にさらに300MBほどメモリを消費していました。 なるべくhttpdにメモリを確保しつつオーバーコミットしないようにメモリ空き容量を微調整し続けていましたが、どうしても10MB程度オーバーしてしまいます。 オーバーコミットするとスワ
サイトの高速化を色々と検証した結果、まずはPHPのアップデートを行うことにしました。 CentOS6のPHPは5.3なのでPHP7まで上げれば3倍のスピードになるはず。 1.アップデートの目的 PHP7導入の目的はWordPress高速化が主な目的ですが、メモリ使用量削減もかなり魅力的。 また十分に高速化できるようなら、WordPress Super Cacheの利用を中止しようと思います。WordPress Super Cacheはアクセスするタイミングによってはモバイルサイトがキャッシュされてしまうので、PCでアクセスしたときに表示がおかしい時があるんですよね。 2.アップデート要件 今回のアップデートの要件です。 運用性を考慮してyumでアップデートする。 ダウンタイムを最小限にする。なるべくmuninのグラフに影響が出ないようにする。 効果がなければ元に戻す。 phpは環境に合わせ
このページを最初にブックマークしてみませんか?
『www.riscascape.net』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く