Solaris 11 for x86からEPYCはどう見えるのか

$ cat /etc/release
                             Oracle Solaris 11.3 X86
  Copyright (c) 1983, 2018, Oracle and/or its affiliates.  All rights reserved.
                             Assembled 02 March 2018

$ prtdiag -v
System Configuration: Dell Inc. PowerEdge R7415
BIOS Configuration: Dell Inc. 1.2.5 03/13/2018
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)

==== Processor Sockets ====================================

Version                          Location Tag
-------------------------------- --------------------------
AMD EPYC 7551P 32-Core Processor CPU1

==== Memory Device Sockets ================================
(以下省略)

ハードウェアをEPYCサーバーにリプレースしました

最初に、5月12～13日の計画停電によるシステム停止で、ご迷惑をおかけしたことをおわびします。

このタイミングでftp.jaist.ac.jpのハードウェアのリプレースを行いました。新しいサーバーはAMD EPYC 7551Pを一つ搭載したDell PowerEdge R7415です。従来はSupermicro 2024GにOpteron 6344を4つ搭載して48コアでしたが、今回はシングルソケットで32コアとなります。

従来からJAISTは、Dellから機材の提供を受けて評価することを継続的に行っていました。今回EPYCを試したい旨打診したところ、DellがEPYCを推していることもあり、機材を提供していただけることになりました。

シングルソケットなのは、Dellが推しているのがこの構成であることと、Solaris 11 for x86のライセンス費がソケット単位なので、ライセンス費が1/4になるJAIST側のメリットが合致した結果です。

リプレースしてからhttpdの動作が安定しなくて、何度かサービスが止まっていますが、近日中に解決する予定です。サービスが安定したら、実運用での新旧サーバーの性能比較を紹介する予定です。

Intel SSD DC P3520を導入しました

3月9日にIntel SSD 750が壊れてからしばらくはL2ARCなしで運用していました。2月末にsourceforge.netがミラーをほぼ全消失させる事故を起こしていたおかげで、アクセスがぐっと減っていたのでL2ARCなしでも乗り切れていました。ミラーが復旧するにつれてHDDの負荷が厳しくなってきたので、4月半ばに新しいSSDを導入しました。

導入したのはIntel SSD DC P3520 2TBです。導入した直後はSolaris 11で認識されなかったり、されても数日で見えなくなったりしていましたが、ファームウェアを MDV10271に更新したところ問題なく使えるようになりました。

Intel SSD 750が壊れました

今朝の10時30分ごろに、ftp.jaist.ac.jpからほとんどデータが流れてこなくなったので様子を見たところ、Intel SSD 750が壊れていました。

Intel SSD 750の耐久テスト(その2)

ftp.jaist.ac.jpでは、Intel SSD 750 1.2TBをZFSのL2ARCとして使用しています。前回に今年のクリスマスに寿命が尽きると予想しましたが、さいわいなことに外れました。以下に、書き込み量とPercentage Usedの推移をプロットしたものを示します。

Intel SSD 750の耐久テスト

ftp.jaist.ac.jpでは、Intel SSD 750 1.2TBをZFSのL2ARCとして使用しています。このSSDの寿命が今日で残り半分になりました。NVMeのSSDの寿命は、SMARTのPercentage Usedという項目でわかります。この値が今日50%に達しました。

キャッシュのヒット率を改善しました

サーバーを交換して以来、キャッシュのヒット率が低くストレージの負荷が高くなっていましたが、メモリを192GBから256GBに増量したことと、L2ARCをチューニングしたことにより、キャッシュのヒット率が上がりストレージの負荷を大幅に減らすことができました。

新しいストレージ構成について

前回述べたように性能には苦しめられたものの、ストレージをiSCSIのボリュームに一度移行したおかげで、HDDのストレージを再構築できました。今回は、24スロットのSASエンクロージャーの2TBのHDDを4TBに交換して、11本構成のRAID-Z2が2組とスペア2本だったのを、6本構成のRAID-Z2を4組にしました。容量は36TBから64TBに増えました。

ようやくサーバーを交換したのですが

前述したように、故障したHDDを抱えて性能が低下したストレージとSun Fire T2000の組み合わせを、iSCSIのストレージを接続した別のサーバーに切り替える作業を1月26日に行いました。サーバーのハードウェアは以前紹介したものです。OSは、性能とZFSの安定運用の観点からSolaris 11のx86版を選択しました。

これでftp.jaist.ac.jpの性能が改善するかと思いきや、iSCSIのストレージの性能が低くかったため逆に悪化してしまいました。ストレージの性能が低かったのは、諸般の事情でiSCSIのボリュームを束ねてRAID-Z2を組んでいたからです。RAID-Zはレイテンシの一番大きなデバイスに足を引っ張られるので、レイテンシのばらつきの大きい仮想化ストレージで組んではいけません。負荷テストをして大丈夫だったからとのことなのですが…

今年のftp.jaist.ac.jpは調子が悪いです

今年に入ってからftp.jaist.ac.jpがすごく遅かったり、落ちていたりすることが増えています。その原因はストレージのトラブルや設計ミスですが、もうすぐ収束する予定です。

最初のトラブルは1月5日に置きました。2組のRAID-Z2のうち一方で3本のHDDが故障して、ストレージが使えなくなったのです。もともと故障したHDDが複数あったのを、ストレージの負荷が高すぎてresilverが終わらないので、あえて放置してありました。ところが、この日にHDDが1本見えなくなりとどめを刺されました。

解決編・「この先のサイトには有害なプログラムがあります」の件

ftp.jaist.ac.jp/pub/のGoogleセーフブラウジングの判定が「疑わしくない」に変わり、Google Chromeがブロックしなくなったことを、4月8日の16時30分ごろに確認しました。前回述べたように、ftp.jaist.ac.jpからSourceForge.net (以下SourceForge)のミラーを切り離したのが功を奏しました。

ftp.jaist.ac.jpがGoogle Chromeに「この先のサイトには有害なプログラムがあります」とブロックされた理由は、以前からあるファイルがGoogleにマルウェアと判定されたことです。ftp.jaist.ac.jpに不正侵入を許したとか、ファイルが改ざんされたといった理由ではありません。

続・「この先のサイトには有害なプログラムがあります」の件

先月上旬からGoogle Chromeでftp.jaist.ac.jp/pub/以下にアクセスすると、「この先のサイトには有害なプログラムがあります」と警告される状態が続いています。前回の記事を書いた時点では、Googleセーフブラウジングによる判定は「疑わしくない」だったので、待っていれば警告が解除されるだろうと思っていました。

「この先のサイトには有害なプログラムがあります」の件

数日前からGoogle Chromeでftp.jaist.ac.jpにアクセスすると、「この先のサイトには有害なプログラムがあります」と警告される状態になっています。本当に有害なプログラムがあるわけではありませんが、そう言われても仕方のない事情があります。

過負荷で接続が困難です

今朝リリースされたCentOS 7へのアクセスが殺到しているため、昼過ぎからftp.jaist.ac.jpへの接続が困難になっています。14時過ぎにはロードアベレージが900を超えました。過去の例では、この辺で処理が詰まって応答しなくなるのでユーザーから見放してもらえるのですが、今回はロードアベレージが1000を超えても処理が継続しているため、負荷が下がらない状況となっています。

どうにもならないので、18時の段階でCentOS 7のディレクトリのパーミッションを落としました。アクセスすると403 Forbiddenになります。CentOS 7をダウンロードする際には以下のいずれかのミラーを使ってください。

• http://ftp.iij.ad.jp/pub/linux/centos/7/
• http://ftp.riken.jp/Linux/centos/7/
• http://ftp.tsukuba.wide.ad.jp/Linux/centos/7/

[2014/7/9 13:25 追記]
CentOS 7のパーミッションはすでに上げてありますが、引き続きほかのミラーへの負荷分散をお願いします。

PC-BSDのミラーをやめました

PC-BSDのミラーをやめました。ずいぶん前にCDNに移行してミラーを使わなくなるとアナウンスが出ていましたが、ミラーの管理人のメーリングリストには、CDNからミラーできるようにするとの案内が来ていたので様子を見ていました。しかし最近、案内がないままミラーのマスターサーバーであるisc.pcbsd.orgが応答しなくなったので、本当にミラーは不要になったのだと判断し、PC-BSDのミラーをftp.jaist.ac.jpから削除しました。

今月はちょっと苦しいです

以下に示したのは、ftp.jaist.ac.jpの一日平均のトラフィックの一年間のグラフです。2月に入ってSourceForge.netの台湾のミラーが一つ止まったため、アジアからのアクセスが増えて急にトラフィックが増えています。

この影響でストレージの負荷がかなり増えていて、キャッシュから外れたI/Oのレスポンスが遅くなる傾向があります。以前説明したように、rsyncによるアクセスはキャッシュミスが多いので、ファイルの転送が遅くなることがあります。

台湾のミラーの停止は一時的なもののようですので、復活すれば性能は戻ると思います。しかし、上のグラフは明らかに単調増加しているので、この調子で行くと今年中に詰みますね。一日も早くハードウェアをリプレースしてほしいです。

ZFSの空き容量には気を付けよう

空き容量の少ない状態で運用してはいけないことは、ZFSを運用する際の常識です。ファイルシステムに書き込むときにコピーオンライトするため、必ずコピーが行われます。空き容量に余裕がないと連続する空き領域を確保できず、書き込みが致命的に遅くなります。そして削除のときもメタデータのコピーが必要なので、空き容量が少ないと削除も致命的に遅くなります。空き領域が足りないのに削除が遅いので詰みます。

ZFSで使用量が90%を超えるのはかなり危険です。しかし、ftp.jaist.ac.jpのZFSの使用量は90%を超えても何の問題もなく、95%に達してもなお問題ありませんでした。書き換えが少ないなら、ぎりぎりまで使っても平気なのかと思っていたのですが、そんなに甘くはありませんでした。Fedora 20をミラーした直後に書き込み性能が大きく低下し、ほかのミラーがとどこおるようになりました。

そこで空き領域を確保するために、まずobsoleteなFreeBSDのpkgngの非公式なミラーと、Scientific Linuxのバージョン4以前のファイルを削除しました。DebianのISOイメージは、古いものから最新のビルドまであらゆるものをミラーしていたのですが、最新のリリース版を残して削除しました。これで使用量は85%まで減りました。

ストレージの容量を増やす方法については現在検討中です。増えたらDebianのすべてのISOイメージのミラーは復活させるつもりです。

UltraSPARC T1のシングルスレッド性能の低さ

小ネタです。先日のプレゼンの中で、UltraSPARC T1のシングルスレッド性能が低いため、日ごろの管理作業でレスポンスが遅くイライラすると言いました。この遅さを表現するために「いつの時代のCPUだよ」と言ったのですが、あまりいい表現ではなかったです。より的確に表現するなら、過負荷のサーバーにログインして作業しているときの「あれ」です。ftp.jaist.ac.jpの場合は、CPUの負荷が50%程度で普通に動いているときでも、ログインするとレスポンスが「あれ」なんです。どれだけイライラするかおわかりいただけますよね。

第九回カーネル／VM探検隊で発表してきました

12月8日に行われた第九回カーネル／VM探検隊でftp.jaist.ac.jpに関する話をしてきました。主にUltraSPARC T1について話しました。わりと変わったアーキテクチャのCPUなので、この会に集まる低いレイヤーに興味がある人たちに楽しんでもらえると思いまして。でも、こんなマイナーなCPUの話題を選んだのに、次の発表者と話題がかぶってしまいました。次の方の話題がUltraSPARC T1のオープンソース版のOpenSPARC T1だったんですよ。これがカーネル／VM探検隊のおもしろいところですね。

ログファイルの圧縮方法

以前紹介したのですが、ftp.jaist.ac.jpのアクセスログの圧縮にはpbzip2を使っています。最初はgzipを使っていましたが、アクセス数の増加とともにログが大きくなって、ディスク容量を圧迫するようになってきたのでbzip2に切り替えました。