WordPressに「いいね」ボタンを追加

WordPressに「いいね」ボタンや「ツイート」ボタンを追加しようと思います。
幾つか方法があるのですが、私が面倒くさがりなので、プラグインで対応しました。
簡単に追加出来ちゃったのですが、問題が・・・「いいね」になって欲しいボタンが「Like」になっていました。
対応を行いましたので、簡単に紹介します。

プラグインの追加

使用したプラグインは「WP Social Bookmarking Light」です。
WordPressでプラグインを追加してください。

「設定」→「WP Social Bookmarking Light」で設定画面が表示されます。

図1 WP Social Bookmarking Light初期設定画面

「Like」→「いいね」に変更する。


「Like」を「いいね」に変更するには、英語表記を日本語表記に変更する必要がありました。

FBタブを選択し、以下の画面を表示します。

図2 FB設定画面

既に変更してありますが、Localeの項目を「en_US」(デフォルト)から「ja_JP」(日本語)に変更し、「変更を保存」とします。

以上で設定完了です。
やってみると簡単だったのですが、この設定が見つからなくてしばらく放置していました。
私の様に悩んでいる人は少ないと思いますが、ご参考までに。

Apache(Webサーバ)のチューニングとベンチマーク

ここでは、Apache HTTP Serverのチューニングとベンチマークに関してまとめます。

Apacheのベンチマーク

Apacheの性能はサーバの性能にも左右されますが、Apacheの設定内容によっても変わってきます。
最近のサーバはそこそこ速くなっているので、デフォルト設定のままでもそこそこ速く動いてくれるのですが、それでもアクセス集中対策を考慮するにはサーバのApacheのチューニングも必要になります。

さて、チューニングの方法は説明する前に、性能測定の方法について説明します。

Apacheの性能測定には、ab(Apache Bench)コマンドを使用します。

色々なサイトでも紹介されていますが、基本的なコマンド操作は以下の様になります。

-n 数値  : リクエストの総数
-c 数値  : 同時接続数

指定したURLに対し「リクエストの総数」分のリクエストを行います。並列して接続するため、「同時接続数」を指定することが出来ます。

試しにabコマンドを叩いてみます。(URLは適当です。)
※絶対に他人のサイトを指定しないでください。DoS攻撃とみなされる可能性があります。負荷試験の一種なので、対象のサーバに高負荷を与えることになります。

ここで注目したいのは、以下の2点です。
Failed requests: 0
Requests per second: 134.39 [#/sec] (mean)

「Failed requests」でリクエストがフェールになった回数をカウントしています。Failが発生しない様に調整する必要があります。

では、調整の仕方を見ていきましょう。

Apacheのチューニング

Apache 2.2系と2.4系ではチューニングの設定が少し異なります。パラメタの名称が一部変更になっているためです。
以下にそれぞれのパラメタ設定例を示します。
ただし、この設定内容は環境により異なりますので、ご自身のサーバ環境によって値を調整してみてください。

Apache2.2系のチューニングパラメタ

Apache 2.2系のチューニング方法を以下に紹介します。今更感はあるのですが、最も効果的な結果が得られたのがこの環境だったので敢えて事例紹介します。

対象ファイル:/etc/httpd/conf.d/httpd.conf

viなどで開いて編集してください。

こちらがデフォルト状態の設定状態です。

こちらが設定変更後の値です。

StartServers1起動時に生成される子サーバの数
MinSpareServers1アイドル状態で待機している
子サーバの最小数
MaxSpareServers5アイドル状態で待機している
子サーバの最大数
ServerLimit10MaxClientsに指定できる上限値
MaxClients10同時接続可能なクライアントの数
MaxRequestsPerChild4000子サーバが処理できる
リクエストの総数

デフォルトの状態では、StartServersが「1」になっていたので、最初の接続に掛かる時間が遅くなる傾向にありそうです。
また、MaxClientsが「10」しかないため同時に処理できるリクエストの数が少なく、こちらも処理が遅くなる傾向にあったようです。
変更後の値に設定し、以下のコマンドでWebサーバを再起動します。

Webサーバの再起動が完了したら、コマンドを実行して動作を確認してみましょう。

主要な内容については以下の通りです。

Failed requests: 0
Requests per second: 601.08 [#/sec]

「Requests per second」の値が134.39→601.08に変化しており、1秒間に処理で来ているリクエストの数が大幅にアップ(約4.5倍)しました。

と、ここで問題です。
MaxClientsを適当にしていしましたが、子サーバ(プロセス)が使用するメモリを考慮して計算しないと、実装メモリよりも多くの子サーバが起動してしまうことになってしまいます。
そうなると、スワップ領域まで達し、最終的にもメモリ不足に陥ることになります。
まず、httpdプロセスがどれ位のメモリを使用しているか?そして、PHPを使用しているならば、PHPの利用するメモリも考慮する必要があります。
実際にサーバ上で動作する際に必要となるメモリ量も気に掛かります。

面倒ですよね。
色々な方が作られている様ですが、MaxClientsを自動計算してくれる仕組みがあります。
その方法について、次に説明を行います。

MaxClientsの自動計算

MaxClientsを自動計算する方法について記載します。
Apache Web Service(Webサーバ)は、並列処理を実現するために複数子サーバを起動して、同時に複数のクライアントから要求されるリクエストに対応します。
その最大値をMaxClientsで指定します。

理論的には、httpd(子サーバ)が利用するメモリとPHPが利用するメモリで1つのクライアントから要求される処理を行うとして、システムのメモリを割ることで値が得られる感じです。
この時、システムでそれ以外に使用するメモリも考慮する必要があり、意外と面倒な計算と情報収集を行うこととなります。

それを自動化してくれる仕組みが以下のサイトにあるスクリプトになります。

https://github.com/richardforth/apache2buddy

apache2buddyを利用してMaxClientsを計算させるには、以下のコマンドを実行し、表示される情報を利用します。

コマンドは以下に記していますが、上記のURLで示されたサイトに記載がありますので(英文ですが)、そちらを参考にされることをお勧めします。(本記事が古くなると使えなくなりますが、上記サイトはメンテナンスされていますので)

重要な箇所は以下の一文です。

Your recommended MaxClients setting (based on available memory) is between 33 and 37. <——- Acceptable Range (10% of MAX)

httpdを再起動した直後などは正確な数値が得られない場合がありますので、本来は24時間程度運用した状態で数値を計算することが望ましいです。

上記の例では、MaxClientsの値として33~37が望ましい値として提示されています。

正直、実験を行ったサーバでは、長時間のヒートランを行っていなかったのでこの値が示されましたが、本来であればもっと少ない値が得られるのではないかと思います。

これを元に、先程示したhttpd.confに記載されている以下の値を調整します。

StartServers
MinSpareServers
MaxSpareServers
ServerLimit
MaxClients
MaxRequestsPerChild

最後に、Webサーバの再起動を行えば設定が反映され安定した動作になると思います。こまめにチェックするというよりも、ある程度時間を空けてチェックすると良いと思います。

apache2buddy以外にも自動計算や手動計算の手法が幾つか紹介されています。
自分に合った方法を見つけることが重要です。
今回の手法は、Linux上での手法となります。Windows上での計算は難しいかな?

incronで起動したプロセスがdefunct(ゾンビ)で残る障害対策

CentOS 7上で2018年12月頃にincronでバグが発生した。

psコマンドを叩いてみると、「defunct」で示されるゾンビプロセスが大量に発生している!

当然のことながら放置すればシステムは暴走しかねない状況にある。
さて、どうしたものか?と思いながら、ゾンビプロセスを殺そうと試みるもkillコマンドでプロセスを殺すことが出来ない。
何故だろう?とその親プロセスを見てみると「incron」が親になっている。

そうこうしている間にもゾンビは増え続けているではないか!?

incronを殺す・・・と言ってkillする必要はないので、以下のコマンドを実行してincronを再起動させてみる

ここでプロセスを確認してみる。

発生していた「defunct」は一掃されゾンビプロセスは綺麗にその姿を消していた。

原因はどうやら「incrond」にあるらしいことまでは、これで特定出来たのだがどうにかならないかと思いながらインターネットを検索するもそれらしき情報がヒットしない。。。しばらくして辿り着いたのが以下のRedHat Bugzillaだった。

https://bugzilla.redhat.com/show_bug.cgi?id=1656939

どうやらincrondのバグが確認されているらしい。
対処方法は、古いソースを入手してリコンパイル&インストールすることになる様だ。当然、現在のincrondを削除しなければならない・・・ということは、設定をメモして云々・・・・(嫌だ!)

そうこうしている間にも、defunctは増え続けていた。
以下のコマンドを実行すると、その数が解る。

出力された数値の左端がその数です。

考えたこと

幾つか対策を考えた

  1. ソースからビルドしてインストールし直す。
  2. 古いバージョンに戻す。
  3. 定期的にincrondを再起動してその場凌ぎをする。

1.ソースからビルドしてインストールし直す

この方法、一見確実な方法である様だが、後にincrondが更新された時にyumで出来要することが出来なくなってしまう。セキュリティホールなどの対応が疎かになってしまう可能性もある。
メンテナンス性が悪いんだよね。出来ればバグ修正が成されたバージョンが提供されるまで待ちたいところなのだが、私の環境下では緊急を要する状況にある。
だめだぁ~( ゚Д゚)

2.古いバージョンに戻す。

では、古いバージョンでは問題が発生していなかったので、バージョンを戻してやろう!
ということで、以下のコマンドで戻せるかチェックしてみる。

残念ながら、古いバージョンのincronは使えそうにない。
もし存在してくれていれば、こんな感じで対応が出来る。

実際やってみると解るが、今回の場合は古いバージョンが存在せず、結果「なにもしませんでした」という寂しいコメントが最後に記されるだけです。

3.定期的にincrondを再起動してその場凌ぎをする。

結局この方法に辿り着きました。

incrondにより生成されたゾンビプロセスは、incrondを再起動することにより削除されていましたので、crondでincrondを定期的に再起動してやることにしました。

まずはcrontabを起動して、定期的にコマンドを実行します。

これで、深夜0時00分にincrondが再起動します。

最後に

この現象は、CentOS7でしか発生していないみたいで、CentOS 6では古いバージョンが使えわれており問題は発生しない感じです。

また、incrondという特殊なパッケージを使っているので、この件に関して悩んでいる人は少ないでしょう

次のバージョンアップで更新されるでしょうし、需要は少ないと思っています。

とは言え、私の備忘録代わりに残しておきます。


concrete5 インストール

背景

concrete5をインストールしたのは覚えていたのですが、インストール方法が解らなくなったので、改めてインストールし直すという恥ずかしぃ〜思いをしながら、まとめ直すとにしました。

対象環境

ここではCentOS 7上に環境を構築します。
多少のパッケージインストール方法は省かせていただきますが、一般的な作業だけ省いているので、概ね問題ないでしょう(^^)

対象OS:CentOS 7.5.1804 (多分、7.xなら同じかと思います。)
他のパッケージ類は適宜インストールしますので、ここでの情報は以上となります。
ちなみにご自身の環境がどうなっているのか分からなければ以下を確認下さい。

ちなみに、作業は全てrootユーザで行います。
一般ユーザでもsudoなんかを使いながら作業を行なえば実現可能ですが、面倒なんで(^^;

準備作業

いつものことながら、インストールする前の準備運動ならぬ下地造りから入ります。

毎度お馴染みのepel-releaseリポジトリの設定ですね。

yum updateコマンドで全体をアップデートして置いた方がよいのですが、私の環境はNVIDIAのドライバをインストールしていたりいろいろと下手なパッケージを更新するとハレーションが発生する可能性があるので、敢えて行いませんが。。。やった方が良いです。

下地造りの前準備?が出来たところで実際に必要なパッケージをインストールします。

と、いきなり間違えました(^^;
単純にインストールすると、PHPのバージョンが古かったはずなので、上記の方法は辞めて以下の方法でインストールを行います。

まずremiで提供されているリポジトリを使えるようにします。

mariadbのインストール

Apache Web Server (httpd)のインストール

PHP5.6のインストール

concrete5 バージョン8以降ではPHPのバージョン 7.2以降を推奨しておりますが、私の環境は既に5.6の環境である程度構築されていたので、PHP5.6をベースにします。

PHPの古いバージョンが入っていた場合には適宜削除してインストール仕直す必要が生じます。(頑張ればなんとかなるなんて思わない方が良いですよw)

unzipのインストール

きっと入ってますよね。でも一応ね。

以上で準備作業は完了です。

concrete5本体のインストール

いつも思うんですけど、本来インストールしようとしているパッケージのインストール作業って、それ程大変じゃないんですよね。どちらかというと下地の準備の方が面倒なんですよね。
そこまできちんとして書いてくれれば嬉しいのですが。。。
そういった意味では、リポジトリって良くできてますよね。
と言っても、勝手にPHPのバージョンが上げられちゃったりすると困るので、結局こうなるのですが。。。

さて、前置きが長くなりましたが、本体のインストールです。

concrete5はWeb上で動作します。また、データベースを利用します。
ということで、httpdとMariaDBをセットアップしておく必要があるわけです。

httpdサービスを起動する。

Webサービスを利用できるように準備します。
毎度のことではありますが。。。

MariaDBサービスを起動する。

データベースサーバを起動します。

データベースサーバはこれで起動しますが、この後にデータベース自体を構築します。

データベースの作成

以下のコマンドを実行し、データベースを作成します。
なお、データベースの作成に関して、各種パラメタをサンプルです。実際のデータベース作成時には、ユーザIDやパスワードを十分に考慮して設定してください。

Firewallの設定

ファイアーウォールが有効になっていると思いますので、HTTPプロトコルが通過できるように設定を施します。

concrete5本体の設置

以下のURLをブラウザで開いて、最新版をダウンロードしましょう。
http://www.concrete5.org/download

Firefoxでダウンロードすると「ダウンロード」フォルダーに保存されますよね。

 

ここから適当なフォルダーへ移動して、解凍して、移動して、パーミッションの設定をイジイジして。。。。という流れを行います。

以上で設置完了です。

うぅーーーーーーー長い!

でも一応のインストールは出来たはずです。
ここからは、順次設定を進めます。

試しに、インストールしたconcrete5を覗いてみましょう!
以下のURLを指定すると閲覧できます。
(リモートで作業を行っている場合はIP

http://localhost/contents/

こんな画面が表示されれば、一応のインストール作業は完了です。

各種設定

言語設定

言語設定を変更します。
「日本語(日本)」を指定します。
#お好きにどうぞ!

環境チェック

実は、ここで「MSQL PDOエクステンションが有効です。」の項目がエラーになっていた。
インストール漏れはなく、設定もされていた。
結論は、Apacheが起動した状態でphp-pdoをインストールしたため、Apacheがphp-pdoを認識していなかったことが原因であった。
Apacheを再起動(systemctl restart httpd)を行うことで、認識した。

ここでは、チェックだけなので、問題がなければ「インストールを続ける」とし次へ進める。
ここで問題があった場合には、必要なパッケージをインストールするなどの対応が必要となる。

サイト情報登録

ここではサイトに関する情報を登録する。
「名前」はサイトの名称となります。
「管理者メールアドレス」は登録会員向けの発信元メールアドレスにもなります。その他、障害通知などもくるのかな?
「管理者パスワード」は編集する際などにログインする場合に使うパスワードになります。データベースのパスワードとは別にした方が良いでしょう。
データベースの各項目にはデータベース作成時に指定した内容を指定します。
今回の例では、
サーバー:localhost
MySQLユーザ名:concrete5
MySQLパスワード:cocrete5
データベース名:concrete5
となっていますが、実際のユーザ名パスワードデータベース名は十分の考慮の上設定してください。
セキュリティ上、上記の設定は宜しくありません。

「concrete5をインストール」ボタンでインストールが開始されます。

しばらく待ちます。

終わったら。。。

これで、concrete5のインストールは完了です。

「サイトを編集」ボタンをクリックすると、編集画面へ遷移します。

編集画面

編集画面をログアウトするには、右上のメニューボタンからログアウトすることが出来ます。

また再度ログインする際には、管理者ユーザが設定されています。
管理者のIDは「admin」です。
パスワードは、設定画面で設定したパスワードとなります。

ログインが上手く行かない場合には、ファイアーウォールを一度停止してみるとか、SELinuxを一度Permissiveにしてみるなどを試してみてください。

今回は以上です。
お疲れさまでした。

その内、操作方法などもアップしてみたいと思います。

cudaGetDeviceCount が-1だった。

OpenCVでcudaGetDeviceCountを用いて、Cudaが利用可能な状態か調べていたのだが、通常はデバイスの認識がされていないと0が返されるところで、-1が返されていた。

結論は、NVIDIAのドライバとcudaのバージョンが合わなかったためでした。

NVIDIAのドライバをバージョンアップすることで、解決しました。

QGIS でラインに対して平行なラベルを付けるには

QGISでラインに平行なラベルを付ける

QGIS 3.4が発表されているのに、今更2.18について何で書いてるのか・・・?という疑問は無視して、QGIS 2.xでラインに平行なラベルを書くための設定を説明します。

 

デフォルトの表示

QGISでラインに対し平行なラベルを表示させようとすると、回転角が上手く計算できずに困ったことはありませんか?
私は、いつも悩みます。
2点で構成された直線aに水平なラベルを描くのですが、回転角によって表示にバラツキが生じます。

デフォルトでは、こんな感じに表示されます。


図1 デフォルト表示

図1に示した表示はデフォルトでの表示例です。
一見、回転角に合わせて表示されている様にも見えますが、線分を360度回転させた時に必ず上もしくは左に表示されています。
今回の目的は、線分の始点(P1)と終点(P2)が反転した場合には、反転して表示して欲しいので、目的とは合いません。

この現象は、QGIS 3.xでも同じようになります。

ちなみに、図1の線分に平行して表示されている数値はP1→P2に向けた線分の回転角になります。

線分の回転角は以下の計算で算出しています。

【数式1】

 

線分の回転に合わせてラベルを回転させる

ここから、線分の回転角に合わせてラベルを回転させる設定を施します。

 

図2 ラベルの配置設定

ラベルの配置設定で以下の項目を設定します。
①「配置」→「許容される位置」→「ラインの方向に依存した位置」を指定します。
②回転の角度を指定します。
回転の角度は以下に示す数式を指定します。

【数式2】

数式1で示した計算で表示出来れば良いのですが、どうも線分の回転角とラベルの回転角は、回転方向が異なっている様です。
その為、「360-」とすることで、回転角を逆方向にしています。
更に、このままですと線分に対して垂直にラベルが表示されてしまうため、最後に「+90」をすることで水平な角度へ変換しています。

QGIS 3.xでは、この計算が異なります。
「360-」を除いた以下の数式になります。

【数式3】

 

次に、レンダリングの設定を変更します。

図3 ラベルのレンダリング設定

ラベルの「レンダリング」で「ラベルを逆さまに表示する」を「回転が指定されている場合」に設定します。

設定は以上になります。

結果は以下の通りです。

図4 結果表示

P1とP2が逆の場合は、応用問題ですから適当に数式を変更するなどの対処が必要となるかも知れませんが、概ねこれで参考情報にはなるでしょう。

【小ネタ】CentOS 6/7における安全なhttpd再起動の再起動方法

小ネタです。

今更感が強いです。

でもメモしておきます。

ここ最近、ブログさぼってました。
ついでに、Apache Http Server 2.2系から2.4系に移行しようとして、ガッツリ嵌ってしまいました。
その結果、ここのブログが10日ほど障害発生&クローズ状態が続いておりました。
閲覧者の方にはご迷惑をお掛けしたことと思います。
お詫び申し上げます。

さて、気を改めて、HTTPサーバを再起動する時に誰かが閲覧中だったりすると困りますよね。いきなりサーバが落ちて正常に反応してくれない!バグってる!!落ちた!!!

そんなことを少しでも起こさない様にしたい!ということで、今回の小ネタです。

CentOS 6における安全なHTTPサーバ再起動方法

コマンドはこんな感じです。

ご存知の方も多いですよね。
今更ですよね。
でも知らない人も多いんですよ。・・・きっとw

CentOS 7における安全なHTTPサーバ再起動方法

CentOS 7ではserviceコマンドが非推奨となってしまいました。
systemctlコマンドへ移行されています。
systemctlコマンドではgracefulのオプションがありません。
ではどうやってやるのか悩ましいところでもあったりします。
でも、以外に解り易いオプション名に変更になったのではないでしょうか?

ということで、コマンドは以下の通りです。

設定の「再読み込み」と覚えておけば、今までよりも解り易くないですか?私だけかな?

ということで、小ネタでした。

 

QGIS2.18と3.0.1のインストールした環境設定一覧

QGIS3.0.1と2.18を共存させた結果のインストーラのパッケージ選択画面を公開しておきます。
私の個人環境なので、他の人が必ずしも同じになるとは限りません。参考情報です。

トライされる方は、前の記事は以下です。

QGIS 3.xをインストールしてみた。QGIS 2.18と共存。

通常不要なものも含まれていると思いますので、ご自身でご判断下さい。

 

QGIS 3.xをインストールしてみた。QGIS 2.18と共存。

背景

QGIS 3.0がリリースされて、OSGeo4Wがインストールされていない綺麗な環境にインストールするのは、何も気にせずにインストール出来たのですが、QGIS 2.18がインストールされている環境にインストールしようとしたら、ちょっとだけ引っかかったので、記録に残します。

既に、QGIS 2.18.xがインストールされている環境を前提に進めます。
インストールを行った環境はWindows 10です。

追記:どうも、QGIS 2.18.xからだと上手く3.0.1をインストール出来たのですが、2.12からだとNGでした。そこで、私の環境設定内容を下記に貼り付けておきます。

QGIS2.18と3.0.1のインストールした環境設定一覧

はじめに

私は、QGIS 2.18.xを使用しており、いきなりQGIS 3.xへ更新するには抵抗がありました。使えなくなるプラグインなどがあり、仕事で使うにはちょっと困ります。
そこで、QGIS 2.18.xを残しつつ、QGIS 3.xをインストールしたいと思いました。

と言うことで、以下ではQGIS 2.18.xを残しながら、QGIS 3.xをインストールしてどちらも使用できる環境を構築します。
ただし、OSGeo4Wを使用していることを前提とします。

準備

準備と言いましても、特に何をダウンロードしてとか必要ありません。
新規でインストールされる方は、下記URLより環境に応じたインストーラをダウンロードしてください。

https://qgis.org/ja/site/forusers/download.html

 

OSGeo4WのSetupを起動します。

ここで、「アドバンスインストール」を選択します。

「インターネットからのインストール」で次へ

次も特に気にせず次へ

更に、次へ。

まだまだ次へ。

 

こいつも次へ・・・・楽々インストール?

やっと来ました!ここから本番です\(^o^)/

「Desktop」の前にある「+」ボタンをクリックして展開します。

ここでは既に3.xがインストールされた状態の画面を示していますが、上記の状態になる様に、インストール対象を選択します。

具体的には、以下の内容になります。

qgis:QGIS Desktop
qgis-dev
qgis-dev-pdb   <==必要ないかも?
qgis-full
qgis-full-dev
qgis-ltr            <==これは2.18を残すためです。それ以前のバージョンを使っている方は、更新されてしまいます。
qgis-ltr-full
qgis-rel-dev
qgis-rel-dev-pdb

これ以外は気にしないで大丈夫です。
上記の中にも不要なものが含まれているかも知れませんが、私の環境ではこんな感じでした。
間違って、3.0.0-4をインストールすると、上手く動作しませんでした。

これで、設定が終わりましたので、次へ進みます。

後は勝手にインストールが進みます。

!!!!!!!!!!!
ここで問題が!!!!!!!
!!!!!!!!!!!

OSGeo4WのSetupでインストールすると、qgis(Desktop)が最初は3.0.0-4しかインストール出来ません。
それが原因でQGIS 3.0を起動してもエラーで落ちる現象が確認できました。

解決方法は、再度、上記のインストール方法を繰り返すと、今度は3.0.1-1がインストール出来る様になります。
これでインストールし直すと、正常に起動出来る様になるみたいです。

Windowsメニューから両方のバージョンのQGISが起動することを確認してみてください。
一つの環境だけしか試していないので、大丈夫かな?