咲島スタンプラリーから【技術的な話】
まずは
運営の方も、参加者の方々も、大変お疲れ様でした。今回のイベントでは、私は運転士でも、参加者でもなく、サーバーの運営・管理をさせていただきました。サーバーが重い中でも、楽しんでいただけた方が多かったようで… 皆様、参加していただき本当にありがとうございました。
サーバー、重い…？
特にイベント開始時、重い、という意見はかなり見られました。参加者側からも、運転士側からも。むしろ声で通っている分運転士からの悲痛な叫びが印象的だったかもしれません。ぶっちゃけ予想はしてました。
データから
結論としては、七島鯖側のサーバーが限界を超えていました。少し誇張してるかもしれないけど。でもかなり無理やり動かしていたようです。
しかも、メモリ不足ではなく、CPU使用率が軒並み高い。
時系列概要
では、サーバーでの重大なイベントログと照らし合わせながら、実際にはどこで重くなっていたか検証してみることにする。
ログの取得方法については、[Linux] ある一定期間のtopコマンドの結果をファイルに出力する（備忘録）、Linuxリソース確認系コマンドの使いドコロなどを参考にした。
・Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz
マシンスペック
・MemTotal: 16298200 kB（16GB）
・Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-170-generic x86_64)
・21:01 log計測開始
top - 21:01:58 up 2:18, 4 users, load average: 0.41, 0.58, 0.68
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
%Cpu(s): 13.6 us, 0.3 sy, 0.0 ni, 86.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16298200 total, 8463584 free, 5771992 used, 2062624 buff/cache
KiB Swap: 564220 total, 564220 free, 0 used. 10208668 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.364g 5.414g 22024 S 54.9 34.8 2:29.53 java
7 root 20 0 0 0 0 S 0.0 0.0 0:01.90 rcu_sched
3170 meitets+ 20 0 22608 5288 3380 S 0.0 0.0 0:00.02 bash計測開始時は、CPU使用率は50%程度、MEM（メインメモリ）使用率も30%程度と、比較的安定した数値であった。
・21:09 一般開放開始
top - 21:09:59 up 2:26, 4 users, load average: 1.90, 0.96, 0.77
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
%Cpu(s): 22.4 us, 1.0 sy, 0.0 ni, 76.3 id, 0.1 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 16298200 total, 10740452 free, 3492604 used, 2065144 buff/cache
KiB Swap: 564220 total, 564220 free, 0 used. 12487528 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.366g 3.244g 22024 S 93.2 20.9 7:13.56 java
1254 meitets+ 20 0 99032 4284 3296 S 0.1 0.0 0:00.49 sshd
7 root 20 0 0 0 0 S 0.0 0.0 0:02.00 rcu_sched人数が増えるにつれ、CPU使用率が93%まで急上昇。メモリはそこまででもない。
・21:55 始発電車発車
top - 21:55:01 up 3:11, 4 users, load average: 2.00, 1.81, 1.74
Tasks: 118 total, 1 running, 117 sleeping, 0 stopped, 0 zombie
%Cpu(s): 38.5 us, 1.8 sy, 0.0 ni, 59.1 id, 0.0 wa, 0.0 hi, 0.6 si, 0.0 st
KiB Mem : 16298200 total, 5548184 free, 8669552 used, 2080464 buff/cache
KiB Swap: 564220 total, 564220 free, 0 used. 7309692 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.431g 8.173g 22024 S 162.8 52.6 62:26.67 java
7 root 20 0 0 0 0 S 0.0 0.0 0:02.60 rcu_sched
3959 root 20 0 0 0 0 S 0.0 0.0 0:00.12 kworker/u8+RTMの車両モデルを出現させると、やはりというべきか、CPU使用率、メモリ使用率ともに上昇。ただグラフを参照するに、メモリ使用率は急激に上昇しているわけではなく、緩やかに上昇しているようである。
・22:02 出坂電車発車
top - 22:02:02 up 3:18, 4 users, load average: 2.48, 2.16, 1.90
Tasks: 118 total, 1 running, 117 sleeping, 0 stopped, 0 zombie
%Cpu(s): 47.5 us, 2.3 sy, 0.0 ni, 49.2 id, 0.1 wa, 0.0 hi, 0.9 si, 0.0 st
KiB Mem : 16298200 total, 5372288 free, 8842740 used, 2083172 buff/cache
KiB Swap: 564220 total, 564220 free, 0 used. 7135352 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.431g 8.335g 22024 S 202.6 53.6 74:47.68 java
7 root 20 0 0 0 0 S 0.0 0.0 0:02.74 rcu_sched
108 root 20 0 0 0 0 S 0.0 0.0 0:01.21 kworker/0:2CPU使用率が200%を超えはじめる。メモリ使用率は50%程度で安定。走行車両数は増減していないからか。
・22:20-接近放送等のバグが頻発
top - 22:20:02 up 3:36, 4 users, load average: 3.20, 3.86, 3.39
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
%Cpu(s): 59.3 us, 3.2 sy, 0.0 ni, 36.4 id, 0.0 wa, 0.0 hi, 1.1 si, 0.0 st
KiB Mem : 16298200 total, 1973788 free, 12223972 used, 2100440 buff/cache
KiB Swap: 564220 total, 564220 free, 0 used. 3753284 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.431g 0.011t 22024 S 254.0 74.3 122:23.85 java
7 root 20 0 0 0 0 S 0.0 0.0 0:03.19 rcu_sched
247 root 20 0 35268 9600 9276 S 0.0 0.1 0:01.27 systemd-jo+だいたいこのあたりがピークで、CPU使用率は250~340%を推移。メモリ使用率も70%を超えていて、かなり厳しい状況だった模様。
・23:04 一時車両全撤去
top - 23:04:05 up 4:20, 4 users, load average: 2.52, 3.09, 3.30
Tasks: 121 total, 1 running, 120 sleeping, 0 stopped, 0 zombie
%Cpu(s): 47.0 us, 1.9 sy, 0.0 ni, 50.3 id, 0.1 wa, 0.0 hi, 0.8 si, 0.0 st
KiB Mem : 16298200 total, 486760 free, 13871208 used, 1940232 buff/cache
KiB Swap: 564220 total, 564168 free, 52 used. 2094980 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.442g 0.013t 22024 S 198.9 84.4 224:00.77 java
7 root 20 0 0 0 0 S 0.1 0.0 0:04.37 rcu_sched
1254 meitets+ 20 0 99032 4284 3296 S 0.0 0.0 0:01.13 sshd
車両クールタイム。CPU使用率は200%を切って、少し安定しだしたものの、メモリ使用率は緩やかに上昇したまま。
・0:00 ログ集計停止
top - 00:00:08 up 5:16, 4 users, load average: 2.93, 3.32, 3.43
Tasks: 118 total, 1 running, 117 sleeping, 0 stopped, 0 zombie
%Cpu(s): 46.9 us, 2.1 sy, 0.0 ni, 50.2 id, 0.1 wa, 0.0 hi, 0.7 si, 0.0 st
KiB Mem : 16298200 total, 688824 free, 15014396 used, 594980 buff/cache
KiB Swap: 564220 total, 552900 free, 11320 used. 966400 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3042 meitets+ 20 0 18.468g 0.014t 20420 S 198.8 91.4 356:16.30 java
7 root 20 0 0 0 0 S 0.0 0.0 0:05.99 rcu_sched
23 root 20 0 0 0 0 S 0.0 0.0 0:00.88 ksoftirqd/3
データの最終結果。CPU使用率は200%弱で安定。メモリ使用率が90%を超えている。クールタイムでも治らなかったということは、アイテムやその他の問題である可能性が高い。
まとめ
では原因は何か？ 考えられる理由は少なくとも以下に挙げられる。
- 過度なサーバー描画距離（描画距離30に設定していた）
- Forgeサーバーの限界（BukkitForgeへの移行が急がれる）
- 単純にサーバーの参加人数が多い（最大接続数52人）
ワールドの負荷問題（これは可能性少…？）- マシンスペックの問題（サーバー用Xeonでは用途に向かない）
サーマルスロットリング（CPUの冷却不足）
4.については、たこたこ氏が極限まで軽量化に尽力されていたので、その可能性については低いと思われる。6.についても、鯖機は「ひんやりしている」（ﾒｲﾃﾂ氏談）らしいので、可能性は低い…でしょう。
今後に向けて
サーバーシステムの再構成を早急に行うことが第一の課題と思われる。KcaldronやThermosなどの改良された1.7.10向けBukkitForgeサーバーへの変更、など…。
未だに技術的な課題は山積しているが、イベント開催的な問題はすでにほぼ解決しているだけあって、こちらの課題が優先事項であることは明確である。よって、早急に以上のような課題を解決するのが、これからに向けての申し送り事項であるだろう。
1件のコメント
RTM向けサーバー構築のまとめ | 箱日本観光振興局 · 2020年3月11日 6:37 PM
[…] 以上のことからも、こちらの記事でも執筆したように、所謂サーバー向けCPU（Xeonなど）ではModを含めたMinecraftサーバーをまともに稼働させることはできないという結果がすでに出てしま […]