スクリプト類とメニューボタン

トップ ソフト 雑記 日記 リンク
ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2022/05/14

データベースサーバのファイルシステムをzfsからbtrfsに切り替えた

1月末から少しずつ作業をしていて、3月に完全切り替えをして、多分もう大丈夫そうなので書き記しておく。 

2014年11月頃から、2TBのSATA HDD 5台をmdadmによる管理でRAID5化していたのですが、障害が出ることが多く、安定性で評判を聞いていたzfs(ZFS on Linux)によるRAID5に切り替えました。

2016年9月頃から速度に不満が出てきて、1ヶ月毎にSSDに入れ替え、オールSSD化されました。

使っていたSSDは、CrucialのCT2050MX300SSD1。これは、HDDから差し替える際に、2TB・2048GBのディスク領域をそのまま移行できるということで選択されました。

この機種を選択した他の理由として、S.M.A.R.T.による監視でドライブの寿命を予測できたというところです。HDDでも、S.M.A.R.T.による監視はできましたが、どうしても駆動部品があるということで、突然死の心配がありました。SSDは駆動部分がないため安定しており、さらにSSDに使われているメモリの書き換え回数に限界があるということで、ある程度寿命に予測が付くのでしょう。

データベースサーバでは、24時間365日、大量の書き込みを行っており、S.M.A.R.T.で取得できる「寿命値」は一定の間隔で下がってくるという様子でした。

S.M.A.R.T.記録グラフ。ここで50%以下にあるグラフがCT2050MX300SSD1。

しかしこの「寿命値」も調べてみると、あくまでも計算式によるもので、0になった瞬間に壊れるわけではないようです。0になった時点で予測されるメモリチップの書き換え回数を消費したということで、0以降はいつ壊れてもおかしくないという状態だそうです。逆に言うと、性能不足のチップがあった場合は0に達する前に壊れる可能性もあるわけです。

実質2017年から使われてきたSSDも2021年で5年間、残り寿命が30%を切りそろそろ不安を覚えるようになりました。

ドライブ寿命については2年ぐらい前から気にしており、HDDからSSDへ切り替えたときのように、また1台ずつ入れ替えていけば良いだろうと、交換するドライブを見繕ってみるとCT2050MX300SSD1は1台6万円ぐらいしていたのに、2TBのSSDが2万円ぐらいまで下がっていました。量産化効果ってすごいですね。しかし容量が2000GBのドライブばかり出てきます。2TiBと2TBの違いでしょうか。

構成サイズが小さくなるようなドライブ交換は、zfsでは対応していないようです。どうしても一度RAIDを解いて、再度組み直す必要があるようです。しかも容量が小さい方に合わせられてしまう。以前仕事で触ったことのあるSynologyのNASでは、Synology Hybrid RAIDという仕様があり、サイズの異なるドライブを組み合わせて無駄なく領域を使ったRAIDが組めるというものでした。こんな仕組みが有ればいいのにと考えていました。

2022年になって、そろそろ次のストレージ構成を真剣に考えなければということで、再び調査をしてみました。相変わらずzfsでは容量減少は対応しておらず、btrfsのRAID5は動作が怪しい。

しかしbtrfsでは異なるサイズのドライブを組み合わせて容量の無駄を極力抑えた状態でRAIDが組めるという情報を見つけました。RAID5のパリティ計算をするCPU負荷も気になっていたので、この際RAID5はやめて、RAID1あたりで構成してみるか?と検討してみました。

Hyper-Vで環境を作り、サイズの異なるディスクの組み合わせでテストしてみたところ、問題なく動作するようです。障害時の復旧手順なども一通りテストして感覚をつかみました。

ということで2000GBのドライブを購入。今回は、CrucialのCT2000MX500SSD1とWESTERN DIGITALのWD Red SA500 WDS200T1R0Aです。他のメーカーを混ぜてみたのは、最近はNVMeのドライブしか買っていなかったので、2TB SATA SSDの使い心地が分からず、Crucial以外の品質も見ておきたかったためです。

新しい2000GBのドライブ2台でbtrfsのRAID1を組み、そこへzfsのデータをコピー。運用してみて動作に問題ないことを確認した後、zfsのRAID5を解放し、従来の2050GBドライブを1台ずつ2台混ぜて4台のRAID1に変更しました。運用しながらRAID構成を変更できるので便利ですね。

しかし思ったより速度が出ず、space_cacheの設定をv1からv2に切り替えてみたりしたもののずっとディスクが足を引っ張るようになりました。1ヶ月ほど調べてみたものの原因がつかめず、最終的にRAID1からRAID10へ切り替え。btrfs的にどのようなドライブの分け方になっているのか分かりませんが、なんとか処理速度も回復しました。

今後は古いドライブから死んでいくはずなので、RAID10に組み込んでいない残りの2050GBのドライブを順次入れ替えつつ、最終的に全部が新しいドライブに入れ替わる予定です。

zfsを運用していた間は、数回だけドライブを認識しなくなることがありましたが、RAID5に組み込み直すとすぐに復旧できたので、信頼度はかなり高いです。ただしzfsはカーネルアップデートの度にビルドし直す必要があります。手元で運用していたときは、画面上ではアップデートが成功しているのに再起動するとzfs領域を認識できなくなるという状態に毎回なりました。一度モジュールを完全にアンインストールして、再度インストールする必要があったので、そこだけが面倒でしたね。

btrfsはカーネルでのサポートも期待できるので、さらに安定した運用ができそうです。


2019/01/27

PostgreSQLのshared_buffers設定とZFSのARCの関係を調べた

いつも個人のプロジェクトではPostgreSQLを使っており、自宅サーバで大きいデータベースを運用しています。最近まではmdadmで組んだRAID-5の上に、ext4でファイルシステムを作って、その中にデータベースのテーブルスペースを置いていました。
しかし、最近ZFSを使い始め、同じようにRAID-Zでファイルシステムを作ってテーブルスペースを置くようになりチューニングを再確認していたのですが、少し気になることが出てきたので調べてみました。

PostgreSQLのshared_buffers設定

PostgreSQLの設定には、shared_buffersというものがあり、搭載されているメモリから共有メモリを確保して、PostgreSQLの各プロセスが利用しています。この値は
1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。 shared_buffersをこれよりも大きな値に設定することが有効なワークロードもあります。 しかし、PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffersにRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。(PostgreSQL日本語ドキュメント 19.4. 資源の消費より)
とあり、あまり大きくしても効果が無いとまで書かれています。
実際にext4でテーブルスペースを管理していた時は、この設定でhtopをみると搭載メモリの利用状況を示すバーの約25%が緑色、約75%が黄色となり、キャッシュが有効に働いていることが確認できました。

ZFSのARC設定

ZFSにはARCと呼ばれるメモリ上のキャッシュ機構を持っています。これは空きメモリから使用され、ディスクから読み出した際にARCにも格納され、同じデータの読み出しが発生した場合はディスクを参照せずここから読み出すことによって高速化を行います。ZFSを開発したSunのエンジニアが、MySQLで使う場合のチューニング指標として
ZFS上でMySQL/InnoDBを利用する場合、利用されるキャッシュにはいくつかの階層が存在します。InnoDB自身がバッファプールを持っていますし、ZFSにはARCがあります。そして、それらのキャッシュは個別に何をキャッシュまたはフラッシュすべきかということを判断するようになっています。そして、それらが同じデータをキャッシュするというような状況が生じてしまうこともあるでしょう。InnoDB内でキャッシュすると、データへたどり着くまでにより短い(そして高速な)コードパスで済むでしょう。そして、InnoDB内でキャッシュミスが生じれば、例えそのデータがARCに存在していたとしてもダーティページのフラッシュが生じてしまうことになります。これは不要な書き込みを生じさせる原因となります。ARCは利用可能なメモリの容量によって(自)動的に縮退・拡張しますが、単にそれを制限する方がより効率的です。我々が実施したテストでは、ZFS内でキャッシュするよりInnoDB内でデータをキャッシュしたほうが7〜200%の性能向上が見込めることを確認しています。(翻訳を紹介している漢(オトコ)のコンピュータ道: 違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング!より)
と紹介されています。このため、データベースでZFSを利用する場合ARCのキャッシュ情報はallではなくmetadataのみをキャッシュするように設定するという紹介をあちこちで見かけます。

鵜呑みにして設定

わたしもこれを読んで同じように設定していたのですが、思った以上にパフォーマンスが上がらず、はてどうしたものかと悩んでいました。そしてふと気が付いたのが、htopで表示されるメモリの使用状況バーは搭載メモリの25%だけが緑でキャッシュが全く使われていない状況でした。つまりメモリの25%しか使っていない状態でした。

ということは、ext4ではOSの標準設定によりキャッシュが働いているからshared_buffersを増やさなくても良いということなのですが、ZFSでキャッシュを最低限にしている場合、shared_buffersを確保した方がいいのではないか?ということです。

そこで、PostgreSQLにおいてZFSを使用する場合、shared_buffersを増やしたときと、ARCのすべてキャッシュするときのベンチマークを取ってみました。

以下の環境でテストを行いました。
  • Core i7-6700(3.4GHz) Windows 10 Pro上のHyper-Vで実行されるCentOS7
  • カーネル 3.10.0-957.1.3.el7.x86_64
  • CPU割り当て4
  • メモリ 4GB(Hyper-Vの動的メモリは使用しない)
  • ZFS 0.7.12(RPMからインストール)
    zfs set recordsize=128K tank(初期値)
    zfs set compression=off tank(初期値)
    zfs set dedup=off tank(初期値)
  • PostgreSQL 11.1(ソースからビルド)
  • pgbench -i -s 100 bench(1000万件)
  • SELECT pg_database_size('bench'); → 1,576,528,895(データベースサイズは約1.5GB)
  • 設定変更後に再起動。一度pgbench -l -T 60 -c 2 -j 2 -P 10 benchで60秒間のベンチを回して、その後5回分のトランザクション数を記録

テストパターンは以下の4種類です。
  1. 両方鵜呑みにする
    shared_buffers=1GB
    zfs set primarycache=metadata tank
  2. ZFSの言うとおりにデータベースのキャッシュを増やす
    shared_buffers=3GB
    zfs set primarycache=metadata tank
  3. PostgreSQLの言うとおりにファイルシステムのキャッシュを増やす
    shared_buffers=1GB
    zfs inherit primarycache tank(デフォルトがallなので)
  4. 一応両方増やす(サイズ的にshared_buffersが優先になるはず)
    shared_buffers=3GB
    zfs inherit primarycache tank

結果


回数\パターン1234
1656590758773
2552670835822
3613543663644
4586656788794
54766741016987
平均値577627812804
中央値586656788794

ZFSのキャッシュをした方が良いという結果になりました。
パターン2はパターン4と同じになるかと思ったのですが、パターン1よりは性能が良いがパターン3より性能が出ないということで、やはりshared_buffersの設定は増やしすぎても効果が無いようです。
またパターン3とパターン4でも差がないことからshared_buffersを増やすぐらいならARCに回した方が良いという結果になりました。

MySQLでZFSを使うシーンに出会っていないので、今回はPostgreSQLの設定だけですが、やはり実際に測ってみないと分からないものだなと感じました。


ちなみに、ZFSのレコードサイズをデータベースとあわせた方が良いという意見を見かけるので、8Kと16Kを試してみたのですが、

zfs set recordsize=8K tank
回数\パターン1234
1696688681689
2701688690704
3686674631716
4627621639654
5683633678657
平均値679661664684
中央値686674678689

zfs set recordsize=16K tank
回数\パターン1234
1678609682683
2713543682688
3543612604668
4592682680663
5667690689717
平均値639627667684
中央値667612682683

大した有意差が見られず、また128Kの方が成績が良かったことから、うちでも8Kにしていたのを128Kに戻しました。
ARCが効きやすいレコードサイズの設定があるのかと思って検索してみたりしたのですが、それらしいドキュメントは見つけられませんでした。ソースをあたるしかなさそうです。

2016/08/23

DDoS攻撃を受けた

8月23日朝、メールボックスを見ると
「【重要】DoSアタック発生による通信回復処理のご報告」
「【重要】DoSアタック発生による通信回復処理停止のご報告」
「【重要】DoSアタック収束による通信遮断処理解除のご報告」
 という3通のメールが届いていた。

内容はosa-p.netのサブドメインのいくつかを収容しているさくらインターネットのVPSに、DoS攻撃が来ていたから通信を切ったよというものでした。
時系列に並べると
  1. DoSアタック検知時刻   :2016年08月22日 15時05分10秒
  2. 通信遮断時刻         :2016年08月22日 15時05分36秒
  3. 通信回復処理時刻     :2016年08月22日 15時05分49秒
  4. 通信回復処理停止時刻 :2016年08月22日 15時12分07秒
  5. 通信遮断処理解除時刻  :2016年08月22日 21時19分28秒
という流れ。

最初DoS攻撃を検知(1)して通信を遮断(2)。
攻撃元をフィルターに追加して通信を回復(3)したのだけど、DDoS攻撃だったためフィルターも数が足りなくなり、回復を断念してサーバごとネットワークから切り離し(4)。
DDoS攻撃が収束したので、ネットワークに復帰(5)した。

メールサーバも同じサーバで管理しており、連絡先アドレスもこのサーバのドメインだったため、完全に事後で知ることになりました。
これはいかんなと思い、連絡先アドレスはgmailに変更。すると再び23日の昼にメールが届きました。
今度は2回目ということもあり、回復処理をすることもなく、いきなりネットワークから切られました。

なかなか回復しそうにないので、どのコンテンツが対象なのか調べてみたところ、ぶろるっくのDNSを自宅サーバに振ってみたところで自宅のRTX1200が反応。
CPU使用率・ファストパスのフロー数・NATのエントリー数がグラフの天井に張り付き、自宅ネットワークが不安定になりました。

さくらインターネットからもらっていたメールに、対象となった通信の概要が載っていたのですが、UDPパケットを投げまくって飽和させるタイプのようで、HTTPロードバランサ辺りを挟んでやれば何とかなりそうです。
cloudflareは以前使ったことがあるのですが、オリジンサーバの応答が遅いとすぐに「このサイトは落ちている」表示にされてしまい全然通信できなかったので、別のサービスを探してみたところ、さくらインターネットの「さくらのクラウド」にウェブアクセラレータがベータ版として公開されていました。
httpでの通信は上手くできたのですが、httpsはウェブアクセラレータのサブドメインとしてしか対応していないようなので、今はhttp専用と思った方が良いでしょう。

しかしVPSで運用していたとき、httpsのヘッダにHSTSの情報を付けていたため、httpのアドレスにアクセスしてもブラウザが自動的にhttps通信へと切り替えてしまいます。
しかも期限を1年としていたので、ブラウザの情報を消さない限り見られないような状態になってしまいました。

ここでVPSへの攻撃がなくなったようで通信が復旧。
HSTSの期限はhttpsのヘッダで返す形になっており、上書きされるようなので、短い時間に設定して元のVPSでサービスを再開しました。

また攻撃が来たら、httpだけで継続できるようにしようと思います。

2012/06/15

tar.bz2なバックアップファイルが復元出来なかった(解決)

tar.bz2なバックアップファイルが復元出来なかった。
bzip2: Data integrity error when decompressing.
        Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: アーカイブ中に予期せぬ EOF があります
tar: アーカイブ中に予期せぬ EOF があります
tar: Error is not recoverable: exiting now
70GBのファイルを20GBまで圧縮してあるのだが、どうやら壊れてしまったようだ。
bzip2recoverを使えということで、使ってみる。
   block 49998 runs from 108483591327 to 108485995530
   block 49999 runs from 108485995579 to 108488398408
   block 50000 runs from 108488398457 to 108490796940
bzip2recover: `all0609.tar.bz2' appears to contain more than 50000 blocks
bzip2recover: and cannot be handled.  To fix, increase
bzip2recover: BZ_MAX_HANDLED_BLOCKS in bzip2recover.c, and recompile.
50000ブロック以上には対応出来ないようだ。
コンパイルし直せとのこと。

http://www.bzip.org/
からソースをダウンロード

bzip2recover.cの真ん中ぐらいに
#define BZ_MAX_HANDLED_BLOCKS 50000
という記述があるので、これを増やすと良いらしい。

tar.bz2のファイルサイズは21,113,008,629なんだけど、どのくらいまで増やせば良いのだろう。
この進捗に表示されている108,490,796,940を調べてみる。
ソースを追いかけてみると、このfromとtoはbStartとbEnd、そして他の場所に
bStart[currBlock] = bitsRead;
という記述があることから、ビット表記らしい。
ファイルサイズをビット換算すると168,904,069,032。
8分の5ぐらいのところまで処理しているようなので、余裕を持って2倍にしてみる。
#define BZ_MAX_HANDLED_BLOCKS 100000
configureなどはないので、直接make。

再度bzip2recoverを実行。
ls
rec15610all0609.tar.bz2  rec31226all0609.tar.bz2  rec46842all0609.tar.bz2  rec62458all0609.tar.bz2  rec78074all0609.tar.bz2
rec15611all0609.tar.bz2  rec31227all0609.tar.bz2  rec46843all0609.tar.bz2  rec62459all0609.tar.bz2  rec78075all0609.tar.bz2
rec15612all0609.tar.bz2  rec31228all0609.tar.bz2  rec46844all0609.tar.bz2  rec62460all0609.tar.bz2  rec78076all0609.tar.bz2
rec15613all0609.tar.bz2  rec31229all0609.tar.bz2  rec46845all0609.tar.bz2  rec62461all0609.tar.bz2  rec78077all0609.tar.bz2
8万近いファイルが生成された。

これを結合しつつ展開
find . -name "rec*.bz2" | sort | xargs -n1 bzcat | dd bs=65536 | tar xvf -

all0609.pgbackup

bzcat: Data integrity error when decompressing.
        Input file = ./rec15012all0609.tar.bz2, output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
どうやらrec15012all0609.tar.bz2がまだ壊れているようだ。
このファイルだけを再度bzip2recoverに掛けてみたが、エラーは消えず。
結局この部分だけを破棄することとなった。

2012/06/10

glibc 2.15のビルドがループする(未解決)

CentOS5.8にgcc 4.7が入っている環境で、glibc 2.15をビルドしようとすると、nptlのところで延々とループしてしまう現象に遭遇した。
検索してみると、「時計が狂ってるんじゃない?アハン?」「VMだったから狂ってたよ!イエアー」みたいな感じで解決してしまっていた。
しかし、うちの場合は実マシンに直接入ってるし、dateコマンドを叩いてみても正しい時刻が返ってくる。

途方に暮れていたところ、別の検索結果から、インストール先のincludeを消すか名前を変えたら上手く行ったよ、という書き込みを発見。
/usr/localにインストールしようとしているときに、/usr/local/includeの方を参照しちゃって、まずいことになるらしい。

早速、
mv /usr/local/include /usr/local/include_org
としてconfigureしてみると、ヘッダファイルが見つからないというエラー。
そ、そうか…。

元に戻して、configureをしてから/usr/local/includeをリネーム。
すると、gd.hが見つからないというエラー。
確かに、gd.hも/usr/local/includeに入っていた。

もう一度、configure --helpを見直すと、gdのインクルードディレクトリを指定するオプションがあった。
もしかして、このために?というようなオプション。

結局、以下のような手順で問題の箇所は通過出来た。

1.ソース展開
  tar jxf glibc-2.15.tar.bz2
2.展開したディレクトリに入る
  cd glibc-2.15
3.ビルドディレクトリを作る
  mkdir -p build
4.ビルドディレクトリに移動
  cd build
5.gdのインクルードディレクトリを参照するためのシンボリックリンクを用意
  ln -s /usr/local/include /usr/local/gd
6.configure
  ../configure --disable-sanity-checks --with-gd-include=/usr/local/gd
7.インストール先のincludeディレクトリをリネーム
  mv /usr/local/include /usr/local/include_org
8.シンボリックリンクの先が居なくなってるので張り直し
  rm -f /usr/local/gd
  ln -s /usr/local/include_org /usr/local/gd
9.make
  make

しかし、その後もmakeでエラーが頻発し、もう前にも後ろにも進めないという状態。
結局諦めた。


1.そもそもの発端は、MongoDBにアクセスするC++プログラムを書きたい。
2.標準で入っているboost 1.33では、古くてビルドが通らない。
3.boost最新版がgcc4.1でビルド出来ない。
4.gcc4.7を/usr/localに入れる。
5.phpが起動しなくなった。
6./lib64に入っているlibc.so.6(glibc 2.5由来)と/usr/local/lib64/libc.so.6(glibc 2.15由来)が衝突している(後者を読んで欲しいのに、前者が読まれる)

というようなことで、いろいろ環境を立ち直らせたかったのですが、gcc4.7はまだ早すぎたようです。

結局CentOS6.2を入れ直して標準のgccのバージョンが上がれば…と期待しつつ、システムを入れ替えることにしました。
アップグレードはサポート対象外とのことで、再インストールを予定しています。とりあえずはyumからのアップデートも試してみようかと思います。成功した報告はないらしいのですが。

2008/03/18

LANカード

事務所では何台かのサーバ機を使っている。
そのうち、1台のLinux機でコンソールに
eth0: Transmit timed out, status 0000, PHY status 782d, resetting....
なんて言うメッセージがときどきでてくる。
お客さんに確認してもらうために公開しているサーバなんだけど、ときどき画像やCSSの読み込みに失敗するという報告が来た。
ローカルネットワークからではそんな現象が起きたことがないのだけど…。

ifconfig eth0
で見てみると、送信パケットでエラーが発生しているらしい。
ググってみても特にはっきりとした原因が分からない。
結局LANカードに使われているVIA製のチップがショボイのではないかという論調。
月曜日の朝にヨドバシへ寄って、安いLANカードでも買おうかと思っていたら、みんなギガビット対応カードばかりだった。
そんな新しいカードはドライバが対応できるかどうか分からないので、出来れば100BASEの枯れたチップがのったカードが欲しかったのだが。

翌日ツクモへ寄ってみたけど、LANカードすら置いてない。
まあ最近はLANポートなんてマザボに標準で着いてるけどね。

蟹チップ(Realtek製)ならまだ安定しているという話を聞いたので、あれば買いたかったのだけど。
それほど深刻な問題ではないので、まあいいか。インテル製チップを買うほどではないしね。

2007/11/23

RRDtoolで日本語

先日書こうと思っていた技術ネタは解決。
CentOS5.0でシステム文字コードをUTF-8からEUC-JPに変えている環境で、manが文字化けする問題について。
ぐぐるさんに聞いてみても、みんなEUC-JPからUTF-8に変えた場合の文字化け解決方法ばかりで、逆方向がなかった。
PAGERを入れ替えたり、nroffのオプションをいじってみたり、いろいろしてたのだが一向に解決せず。

落ち着いて深呼吸したらman.confの
JNROFF /usr/bin/groff -Tnippon -mandocj

JNROFF nkf -e | /usr/bin/groff -Tnippon -mandocj
に変えるだけでよかった。

うーん、いまいち仕組みが分かってないんだけど、もともとの後者の問題は
man(EUC-JP)→nroff(EUC-JP)→less(EUC-JP)→表示(UTF-8)文字化け
なのかね。
だとしたら前者の問題は、システム文字コードをEUC-JPにしてるんだから、そのまま表示してくれたらいいだけなのになぜが文字化け。
nroffの前にnkfで文字コードを変換する必要があるってことは、manの内容はUTF-8で書かれてるんだろうか?
どっかでmanはEUC-JPだから、EUC-JPで書かれているmanをUTF-8に一括変換する方法とか書かれていたので、manはEUC-JPだと思いこんでいたんだけど、ディストリビューションによって違うのかな?
まあ、とりあえず、今のところ問題はなさそうなので、これでよしとする。


んで、もういっこの問題。
サーバの動作状況をグラフ化したくて、RRDtoolを入れてみた。
グラフ内に日本語を使いたかったので、マルチバイト文字を使う方法を探してみたんだけど、ネットにある情報はほぼ1.0.xに日本語化パッチを当てるというもの。
うーん、どうせなら最新の1.2.xで使いたいなぁ。
んで、調べてみると、ELF氏のサイトで1.2.xでマルチバイト文字が使えるという情報が
そのサイトには具体的な方法は書かれていなかったけど、configureのオプションを見てみたら、--with-rrd-default-fontなるオプションが。
さっそくIPAモナーフォントを落としてきてインストール。
configureを流して、make、make install。
しかし文字化け。いや、「最大」の「最」だけ見えてたり、全然関係ないアルファベットが表示されていたり。
うーん、やっぱり日本語に対応してないんかな。と、再度検索の旅へ。

どうやらここでも文字コードの問題か。RRDtoolが依存しているGD2で、EUC-JPを使うときは-DXJIS0208のオプションが必要だとか。
というか、ソースに入ってたreadme.jpnに書いてあったよ。説明系の文書ってREADMEとか大文字のファイルになってるからlsしたときに先頭に来てるファイルしか見てなかったよ(;´Д`)
readme.jpnを読むと、文字列を扱うときにiconvでごにょごにょすることもできるらしい。
さっそくiconvも使うようにconfigureを流してmake。
あれ?なんかエラーになったよ。iconvが見つからないらしい。コンパイルオプションで指定してみたり、Makefileを書き換えてみたりしたがどうにも認識しない。
GDのコンパイルを説明していたサイトには、同じオプションでiconv付きのコンパイルが成功しているんだけど。
samba3を入れるときにiconvにパッチを当てたのが原因か?それ以前の問題だと思ってるんだけどなぁ。
結局GDでEUC-JPを使うのは諦める。
UTF-8で何とかすりゃいいんかいな?と思い、rrdtoolのグラフを書くときに、nkf -W8とかで項目名を流し込んでみたが、やっぱり文字化け。
IPAモナーフォントが悪いのだろうかと考え、さざなみフォントを入れてみたが、IPAモナーフォント以上になにもでない。
結局これも諦めて標準で付いてきたDejaVuSansMono-Roman.ttfを使いましたとさ。

うーん、GDに問題があるとすれば、PHPからグラフを描く要件もあるんだけど、そこでも文字化けするんかいな。これも要調査。

2006/11/27

phpMyAdminのアップロード

仕事メモなので今日のは読んでもよく分からないと思います。
…毎日大して変わらないか。

画面写真仕事で本番環境のデータベースを作ろうと、テスト用DBから本番DBへダンプファイルを移した。
テスト用サーバでphpMyAdminを使ってダンプデータを吐き出し。
本番環境のphpMyAdminでダンプデータをアップロードしたんだけど、何度やっても途中で失敗する。

ダンプファイルをSQL形式にして一行ずつ実行したら動くけど、十数万件のマスタが有るのでそんなことやってられない。
拡張SQL形式にして千件ずつぐらいにしたら動くんだけど、ときどき返答が帰ってこなくなる。
一括で流すとSQLの区切りがおかしいとか言われるし。

原因も分からなかったけど、あきらめて今日は帰るかーと、帰宅してからアップロード画面に文字コードを指定するラジオボタンがあったなぁと思い出す。
事務所のマシンに遠隔で入って試した。

DBもダンプファイルも文字コードはEUC-JPだったんだけど、アップロード時に「EUC-JPに変換」にチェックが入っていると、なぜか認識に失敗する行があるようで、そこでエラーになるようだ。
文字コード変換を「non」にするとすんなり入った。
なんで変換するのがデフォルトなんだよ。

2006/09/21

Unix

以前、仕事の開発用にFedora Core3でサーバを作った。
各種プログラムをrpmで入れたんだけど、PHPのバージョンが4.3.11で作っているプログラムがPHPの不具合で動かなかった。
本番環境に合わせてバージョン4.4.4を入れたかったんだけどrpmが公開されていない。
仕方なくソースを拾ってきてコンパイルして…って面倒だなぁ。

結局細かくいろいろ入れ替えようと思ったら、全部ソースから作らないといけないし、rpmの存在意義がよくわからんな。

2005/11/12

はやぶさ、すごい。超すごい

イオンエンジンのテストのついでに
地球スウィングバイのテストのついでに
自律航法で他の天体とランデブーするテストのついでに  ←いまここ
イトカワの科学観測をするついでに
イトカワにタッチしてサンプルを採取するテストのついでに
地球に帰還してカプセルを大気圏に再突入させて回収するテストのついでに
イトカワのサンプル入手するテスト

予算が少ない中でとてもよくやっていると思う。
イトカワと「はやぶさ」の影
こんなん見ると、なんか感動しますなぁ。
もともとイオンエンジンのテストなのに、これで帰還できなかったらマスコミは失敗失敗って騒ぐんだろうなぁ。
「はやぶさリンク」:11月10日午後5時からの記者会見詳報
どこの記者も資料を読んでない(大手なら科学部ぐらいあるだろ)し、取材らしい取材は週刊ポストぐらいか(笑)


NTTデータが独自開発オープンソース・セキュアOS「TOMOYO Linux」を公開,ポリシーの自動学習機能を備える
セキュアOS「TOMOYO Linux」を公開。
NTTデータでは,TOMOYO Linuxに先立って,ルート・ファイルシステムを読み取り専用にしてシステム・ファイルの改ざんを防止する「SAKURA Linux」を開発している。またデバイス・ファイルの改ざんを防止するため/devをアクセス制限付きにしたファイル・システム「SYAORAN」,認証機構の「CERUBERUS」も開発している。

NTTデータはアホじゃないだろうか(褒め言葉)。しかしよく承認したな。
TOMOYO Linuxは,Sourceforge.jpの同プロジェクトのページからダウンロードできる。
プロジェクト管理者と発表者の名前が一緒だ。この人がCCさくら好きなのか。

2005/10/23

原因不明トラブル

土曜の朝、起きるとWebサーバが止まっていた。
同じマシンで動いているデータベースのリカバリをさせていたら変なデータが有ったらしくそこで再起動してしまうらしい。
ついでにディスクのどっかが壊れたようで、Apache2が起動しなくなっていた。
日記が表示できないので、手動でApache2を立ち上げようとしたらエラーで立ち上がらない。
ログによるとPHP4と連携するためモジュールが存在しないと書かれてあるけど、ファイルは確かにそこにある。
よくわからんので、ついでにApache2とPHP4のバージョンを上げて、再度立ち上げ。
…やっぱりだめ。
とりあえず出かける用事があったので、Apache2にPHP4のモジュールを読ませないようにして出発。
帰ってきてからもう一度立ち上げてみたら動いた。
なんだったんだろう。

広告