このページの翻訳:
ソースの表示
最近の変更サイトマップ

FreeBSDのif_bridgeが5倍速くなるらしい

FreeBSDのネットワークブリッジ機能、if_bridge(4)が遅いってのは以前書いたとおりなのだけど、今後、おおむね5倍に高速化される見込みらしい。

FreeBSD Foundationの記事によれば、現状のif_bridgeは、重いBRIDGE_LOCK mutexのせいで、CPUのコア数によらずスループットは最大3.7Mpps程度に制限される。この度、Kristof ProvostがFreeBSD 13-CURRENT上でロックフリーのepoch(9)を使った実装にしたところ、概ね18.6Mppsのパケットフォワードが行え、5倍の改善となったとのこと。

これはなかなかムネアツ。

一方で、現状の実装でも3.7Mpps出るってことは、最大フレームなら理屈上41Gbpsの帯域を有するハズ。にもかかわらず、iperfの実測で3.5Gbpsほどに止まるのは何でだろーなー。全二重通信で帯域が分割される点を考慮しても低すぎのような気が。

参考サイト

PostgreSQLをDBドライバ経由で使った時の「SSL error」はスレッド周りを見直す

超絶ハマったのでメモ。

QtのPostgreSQLドライバ(QSqlDatabaseの“QPSQL”)で連続したクエリを大量に発行すると、ポスグレのログに以下のようなログが記録されて正しく実行されない現象に遭遇した。

2020-06-11 19:41:00.598 JST [2593] db@postgres STATEMENT:  DEALLOCATE qpsqlpstmt_10
2020-06-11 19:41:00.633 JST [3924] db@postgres LOG:  SSL error: decryption failed or bad record mac
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  could not receive data from client: Connection reset by peer
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  unexpected EOF on client connection with an open transaction
2020-06-11 19:41:00.645 JST [3925] db@postgres ERROR:  invalid input syntax for type timestamp: " " at character 77
2020-06-11 19:41:00.645 JST [3925] db@postgres STATEMENT:  EXECUTE qpsqlpstmt_16 (TIMESTAMP WITH TIME ZONE '2020-06-11T10:41:00.634Z', '[, )', FALSE, 0, 0, 0, 0, 0, 10, '', 0, 2020061110480001, 0, 1, 0, 10)
2020-06-11 19:41:00.646 JST [3925] db@postgres WARNING:  there is no transaction in progress
2020-06-11 19:41:56.266 JST [12492] db@postgres LOG:  SSL error: tlsv1 alert protocol version
2020-06-11 19:41:56.272 JST [12492] db@postgres LOG:  could not receive data from client: Connection reset by peer

Qt側のログは消失してしまったが、SSL SYSCALL Resource temporarily unavailableSSL SYSCALL error: EOF detectedといったエラーが出てDBとのコネクションが破壊され、トランザクションに失敗したりとかそんな感じ。

両方のログから読み取れるのは、クエリ発行時にプログラムとポスグレ間のSSL接続が通信途中で切れたり、データが破壊され変なクエリを実行しようとしたり、SSLの認証に失敗したりしてる。どーしてそんなことが起こるの?

それらしい単語でググると、postgresのSSLを無効にして解決とか出てくるけど、それって何の解決にもなってなくね?っていう。自分が加えた変更以後に発生するようになったので、原因は間違いなく自分ってことだけはハッキリしてる( ˘ω˘ )。

DBドライバとコネクションについて調べ、コードを追ってみたところ、スレッドをまたいで同一のDBコネクションを使ってたのが原因のようだった。一般的に、1つのデータベースコネクションを複数のスレッドで操作するのは禁じ手だそうで、Qtのドキュメントにも

A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported.
(訳:コネクションは生成されたスレッドからしか使用できない。コネクションのスレッドをまたぐ移動や異なるスレッドからのクエリ生成は非対応。)

という記述がある。でーびーしょしんしゃなのでしらんかった。

DB操作スレッドで作られ使われていたコネクションに対し、今回メインスレッドからクエリを発行する変更を加え、なおかつ、特定の操作を行うと両スレッドが入り乱れてコネクションを使うために、問題が顕在化したようだった。

というわけで、メインスレッド用に別途コネクションを用意し問題を回避した。解決ではなく回避なのは、かなりアレな設計で緊急措置的な対応だから…。元の構造がアレすぎていい対処方法が思いつかなかったの……。

Transcend TS32GMTS400 32GBのベンチマーク

ルータ用にと思って買った小型PCに、トランセンドのM.2 Type 2242なSSD MTS400シリーズの32GB、T32GMTS400が入っていたのでベンチなんぞを取ってみる。公式サイトによると、32GB版のスペックは読み込み200MB/s、書き込み40MB/s、90TBWの2DWPD(3年)となっている。

ディスクの状態は↓こんな感じ。新品で買ったPCの割に電源投入回数と書き込み量が多いような…。

ベンチは↓な感じ。

------------------------------------------------------------------------------
CrystalDiskMark 7.0.0 x64 (C) 2007-2019 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
Sequential 1MiB (Q=  8, T= 1):   279.169 MB/s [    266.2 IOPS] < 29939.73 us>
Sequential 1MiB (Q=  1, T= 1):   268.454 MB/s [    256.0 IOPS] <  3902.29 us>
    Random 4KiB (Q= 32, T=16):   107.224 MB/s [  26177.7 IOPS] < 19488.81 us>
    Random 4KiB (Q=  1, T= 1):    28.066 MB/s [   6852.1 IOPS] <   145.41 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):    53.481 MB/s [     51.0 IOPS] <153808.46 us>
Sequential 1MiB (Q=  1, T= 1):    53.065 MB/s [     50.6 IOPS] < 19666.44 us>
    Random 4KiB (Q= 32, T=16):    53.459 MB/s [  13051.5 IOPS] < 39015.26 us>
    Random 4KiB (Q=  1, T= 1):    52.687 MB/s [  12863.0 IOPS] <    77.35 us>

Profile: Default
   Test: 1 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/04/12 13:20:08
     OS: Windows 10 Professional [10.0 Build 16299] (x64)
Comment: Transcend TS32GMTS400

カタログスペック以上の速度は出ているが、最初期のコンシューマ向けSSDと比べても遅めですな…。128GB版でも書き込み160MB/s程度っぽいので、このシリーズはこんなものなのだろう。

参考サイト

FreeBSDのL2ブリッジ(if_bridge)は本当に遅かった

FreeBSDでL2ブリッジを有効にするとネットワーク性能が激烈に落ちるという話がある。なんでも、ブリッジの実装であるif_bridge(4)に存在するたくさんの最適化されてないロックのせいで性能劣化を引き起こしてるとか。

いやいや、いくら何でもそんなに変わらんやろ?と思い、ブリッジの有無でiperfしてみたら、ブリッジ有りの方でありえないほど遅くなって草も生えないんですが。

測定環境は下表の通り。ネットワークまわりのチューニングとかは特にしてない。

サーバ クライアント
OS FreeBSD 12.0-RELEASE-p4 amd64 Windows 10 Pro 1903 x64
CPU Xeon E5-2648Lv3 Ryzen 1700
NIC ConnectX-3 Pro EN (L2SW経由で40Gb接続)
ソフト iperf 2.0.13 iperf 2.0.14a

ご覧の通り、現状のif_bridgeは1GbEには十分だけど、10GbE以上の環境では完全ボトルネックとなってしまう。bhyve使うときに割と困るぞこれ…。

参考サイト



いつのまにかZoLとOpenZFSが統合されてた&永続的L2ARCが来るっぽい

ZFSのLinux向け実装であり今やZFS開発のメインストリームであるZFS on Linux (ZoL)が、いつの間にかOpenZFSと統合されていた。統合されたというより、OpenZFSがZoLベースで仕切り直され、ZoLがOpenZFSと名前と変えたと言った方が近いのかも?

経緯はともかく、既にZoLのGitHubはOpenZFSのリポジトリへとリダイレクトされるようになっている。で、2020年、すなわち今年にはZoL 0.8をベースとしたOpenZFS 2.0がLinuxとFreeBSD向けにリリース見込みのようだ。この辺のロードマップはOpenZFS Developer Summitでの発表資料(PDF)に詳しい。

また、そう遠くない未来に永続的L2ARC (Persistent L2ARC)が取り込まれるようだ。

ZFSerにはご存じのとおり、L2ARCはSSDなどの高速ストレージを使ったZFSの読み込みキャッシュの仕組みである。後から必要な時に有効化できる簡単便利な仕組みだけど、システムの再起動でキャッシュ内容が失われてしまう欠点がある。より正確には、ストレージ上にはキャッシュデータが残っているものの、メモリのキャッシュ管理データが消えてしまうため、現状のL2ARCは事実上の揮発性キャッシュとなっている。

永続的L2ARCでは、その名前のとおりシステムが再起動しても以前のキャッシュが維持されるようになる。ちなみに、L2ARCの管理データは無視するには大きいサイズなので、あまり巨大なL2ARCを作るとメモリを圧迫しL2じゃない方のARCが減るという本末転倒な事態に陥るので注意が必要。

機能自体はOpenZFSのロードマップにも以前から記載があり、2015年にillumos向け実装の移植が試みられていたようだが、結局実現はしなかった。ところが最近になって、これまたZoLパワーでもって急速に開発が進められている。現時点でOpenZFS 2.0リリース予定には組み込まれていないものの、既にプルリクが作られており近々masterに取り込まれそうな勢いである。Linuxパワーしゅごい……。

参考サイト

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0