Nicolは仕事用や実験用など、国内外含め幾つかのVPSを契約しています。中でも勉強やお試し用におすすめしているのが、Time4VPSです。レンタルしたサーバは使っていない時間帯はMinergateでマイニングを行っているのですが、ある時ふと実行結果を見てみると全く同じスペックで契約しているサーバにも関わらずマイニングのHashrate（採掘速度）が大きく異なっていました。
本記事ではその原因の調査結果について共有したいと思います。
Time4VPSのサーバ契約はこちらから↓
Time4VPSでサーバ契約＆マイニングをはじめる方法はコチラを参照ください↓
[サーバA]
[21.11.2017 03:30] [ info] New Job: job_id=”42626ff5-b14e-44fb-bfc
2-ccb157cc299c” blob=”0606b483ced005caac2f05cdb040d10e85e78da4e4cd1
9db18ca439807a6eb697590fa9c508d390000000090cb987b75b16a82093392d898
b017346e77da8f78dcfa9b2c02ea9147d873a309″ target=”6e128300″
[21.11.2017 03:30] [ info] New difficulty: 500
XMR hashrate: 12.10 H/s
XMR hashrate: 9.90 H/s
XMR hashrate: 10.20 H/s
[サーバB]
[21.11.2017 03:30] [ info] New Job: job_id=”062d63fc-4f2e-4c33-a9d
2-db91e52540e1″ blob=”0606b483ced005caac2f05cdb040d10e85e78da4e4cd1
9db18ca439807a6eb697590fa9c508d39000000004850044de1066cf71eec7a07d1
422fb565608983b1b33aa9c5f9d9303df5494809″ target=”6e128300″
[21.11.2017 03:30] [ info] New difficulty: 500
XMR hashrate: 3.20 H/s
XMR hashrate: 3.81 H/s
XMR hashrate: 4.09 H/s
difficulty:採掘難易度。基本的には値が小さいほど難易度が高い。
hashrate:採掘速度を表しており、秒間のハッシュ計算回数をH/sで表している。
画像のようにNicolはTime4VPSで3台のサーバを契約しています。アプリを動かしたり、実験をしたりと行った使い方をするために契約していますが、放置しているともったいないので勉強がてらマイニングしている、という程度の使い方です。大した量が採掘できるわけでもないので（本当に全然掘れてません。。）hashrateが低い事自体は気にしていませんが、同じ契約にも関わらずこのhashrateの差は何なのかは非常に気になったので調査してみました。
サーバAの契約内容
サーバBの契約内容
上の画像のように、プランの契約内容的には同一で、サーバスペックをざっと見てみても違いがわからなかったので、純粋なCPU性能を図ってみることにしました。
CPU性能測定（簡易）
簡易性能測定コマンド（CPU）
time for ((i=0;++i<1000000;)); do :; done
[サーバA]
[root@SERVER_A ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m14.192s
user 0m6.827s
sys 0m0.046s
[root@SERVER_A ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m14.254s
user 0m6.817s
sys 0m0.056s
[root@SERVER_A ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m14.481s
user 0m6.741s
sys 0m0.050s
[root@SERVER_A ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m14.418s
user 0m6.886s
sys 0m0.042s
[root@SERVER_A ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m14.444s
user 0m6.835s
sys 0m0.075s
約14秒で安定していますね。
[サーバB]
[root@SERVER_B ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m17.761s
user 0m7.089s
sys 0m0.104s
[root@SERVER_B ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m24.268s
user 0m7.239s
sys 0m0.141s
[root@SERVER_B ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m21.531s
user 0m7.389s
sys 0m0.181s
[root@SERVER_B ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m19.403s
user 0m7.142s
sys 0m0.134s
[root@SERVER_B ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m21.258s
user 0m7.251s
sys 0m0.138s
こちらは回によってばらつきがありますが、約20秒といったところ。
単純なコマンドによる比較ですが、確かにサーバBのほうが遅いことがわかりました。しかし問題はなぜこの差が生まれているのかという点です。
サーバの基本情報をチェック
OSバージョン
[サーバA]
[root@SERVER_A ~]# cat /etc/redhat-release
Fedora release 22 (Twenty Two)
[サーバB]
[root@SERVER_B ~]# cat /etc/redhat-release
Fedora release 23 (Twenty Three)
OSのバージョンが異なっています。
CPU情報
[サーバA]
[root@SERVER_A ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
stepping : 2
microcode : 57
cpu MHz : 1172.815
cache size : 20480 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmu
lqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_s
hadow vnmi flexpriority ept vpid fsgsbase bmi1 avx2 smep bmi2 erms
invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips : 4794.26
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
[サーバB]
[root@SERVER_B ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
stepping : 4
microcode : 1064
cpu MHz : 1171.329
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 6
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmu
lqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pci
d dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi fle
xpriority ept vpid fsgsbase smep erms xsaveopt
bogomips : 4788.19
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
OSバージョンとCPU情報の一部が異なっています。わかりづらいので表にして比較するとこんな感じです。
CPUのバージョンが異なっていますね。
一応、CPUの機能のフラグであるflagsの内容も比較。詳細は調べていませんがサーバAのほうがflagsの要素が多いです。
リソース状況の比較
下記はリソース状況を確認してみた結果です。
[サーバA]
[サーバB]
サーバAのCPUがほぼ100%で張り付いているのに対して、サーバBのほうが若干CPUに空きがあるようにみえる点が気になりますが理由まではわかりませんでした。
マイニング実行時のtopコマンドの出力
[サーバA]
top – 04:42:53 up 30 days, 13:34, 1 user, load average: 1.07, 0.
Tasks: 31 total, 1 running, 30 sleeping, 0 stopped, 0 zomb
%Cpu(s): 90.9 us, 9.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.
KiB Mem : 524288 total, 332576 free, 20764 used, 170948 b
KiB Swap: 262144 total, 260188 free, 1956 used. 331682 a
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
1420 root 20 0 548228 13880 8000 S 52.2 2.6 7:20.13
1428 root 20 0 52384 2056 1500 R 4.3 0.4 0:00.48
1 root 20 0 43480 2988 1704 S 0.0 0.6 2:06.36
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00
3 root 20 0 0 0 0 S 0.0 0.0 0:00.04
88 root 20 0 164284 50812 50524 S 0.0 9.7 7:43.98
98 root 20 0 41664 1316 940 S 0.0 0.3 0:00.01
125 root 20 0 576356 37360 36100 S 0.0 7.1 2:07.83
128 root 20 0 24196 1324 1140 S 0.0 0.3 0:22.57
129 root 20 0 242848 4884 2956 S 0.0 0.9 1:20.20
134 root 20 0 80956 3520 2820 S 0.0 0.7 1:09.36
135 dbus 20 0 52028 1840 1460 S 0.0 0.4 0:59.94
141 root 20 0 25512 552 344 S 0.0 0.1 0:00.00
144 root 20 0 69708 784 276 S 0.0 0.1 0:00.00
149 root 20 0 69708 532 32 S 0.0 0.1 0:00.00
170 root 20 0 88740 2076 492 S 0.0 0.4 0:54.09
202 smmsp 20 0 84160 1792 452 S 0.0 0.3 0:00.56
274 root 20 0 6380 784 680 S 0.0 0.1 0:00.00
275 root 20 0 84480 1696 1560 S 0.0 0.3 0:00.03
495 root 20 0 42720 1368 1328 S 0.0 0.3 0:00.00
497 root 20 0 74984 1072 76 S 0.0 0.2 0:00.00
499 root 20 0 11808 1736 1484 S 0.0 0.3 0:34.45
612 root 20 0 20588 1076 916 S 0.0 0.2 0:02.55
1374 root 20 0 20592 696 500 S 0.0 0.1 0:00.00
1375 root 20 0 9572 1496 1292 S 0.0 0.3 0:00.00
1377 root 20 0 4260 552 468 S 0.0 0.1 0:00.00
29069 apache 20 0 253092 3776 1768 S 0.0 0.7 0:00.00
30433 apache 20 0 253092 3776 1768 S 0.0 0.7 0:00.00
31523 apache 20 0 253092 3768 1772 S 0.0 0.7 0:00.00
[サーバB]
top – 04:42:56 up 18 days, 18:48, 1 user, load average: 1.08, 1.
Tasks: 26 total, 1 running, 25 sleeping, 0 stopped, 0 zomb
%Cpu(s): 93.1 us, 6.9 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.
KiB Mem : 524288 total, 268000 free, 18652 used, 237636 b
KiB Swap: 262144 total, 257424 free, 4720 used. 318018 a
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
24802 root 20 0 548712 14284 8288 S 49.1 2.7 5:29.26
1 root 20 0 131716 2660 1568 S 0.0 0.5 1:18.34
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00
3 root 20 0 0 0 0 S 0.0 0.0 0:00.02
90 root 20 0 247380 82268 82088 S 0.0 15.7 3:17.67
92 root 20 0 41792 676 492 S 0.0 0.1 0:01.08
123 root 20 0 274420 5888 3692 S 0.0 1.1 0:55.95
124 root 20 0 24296 1104 880 S 0.0 0.2 0:15.54
125 root 20 0 495396 51528 50392 S 0.0 9.8 1:00.75
129 dbus 20 0 54696 1036 816 S 0.0 0.2 0:43.61
130 root 20 0 24988 304 276 S 0.0 0.1 0:00.00
147 root 20 0 71796 360 228 S 0.0 0.1 0:00.00
151 root 20 0 71796 140 28 S 0.0 0.0 0:00.00
155 root 20 0 83044 624 424 S 0.0 0.1 0:28.93
167 root 20 0 88780 724 408 S 0.0 0.1 0:42.48
215 smmsp 20 0 84196 1128 384 S 0.0 0.2 0:00.33
495 root 20 0 6412 348 340 S 0.0 0.1 0:00.00
575 root 20 0 22688 592 452 S 0.0 0.1 0:01.70
17825 apache 20 0 524484 4620 2112 S 0.0 0.9 0:28.20
18765 apache 20 0 295044 4396 2100 S 0.0 0.8 0:30.99
22691 apache 20 0 295044 4388 2096 S 0.0 0.8 0:08.30
24697 root 20 0 102692 2752 2016 S 0.0 0.5 0:00.17
24704 root 20 0 44960 2520 1968 S 0.0 0.5 0:00.00
24706 root 20 0 174320 1408 96 S 0.0 0.3 0:00.00
24709 root 20 0 11828 2008 1636 S 0.0 0.4 0:36.82
24810 root 20 0 52768 2072 1516 R 0.0 0.4 0:00.43
赤の太字になっているプロセスが、MinergateのAPIです。どちらのサーバでも最も多くのCPUリソースを使っていることがわかります。それ以外は特別プロセスの状態に差は見ないように見えます。
[adsense]ここまで調べて原因を考えてみた
疑惑１．採掘ツール実行設定の違いによりhashrateに差が出ている？
念のため確認してみましたが、採掘対象の通貨も同一だし実行時の設定（実行コマンドと引数）も同一でした。
疑惑２．VPSのホストから制限を受けた？
CPUをぶん回しすぎてTime4VPSから怒られるケース。これまで特に制限をかけずに、時間帯によってはCPU100%で処理し続けていたため十分に考えられる事態だと思います。
ダッシュボード上のステータスを確認したところ、特に制限されているような様子は見て取れません。また、登録したメールをチェックしてみましたがこちらも特に連絡などは来ていませんでした。海外のサービスですので、無告知でしれっと制限されている可能性も無きにしもあらずですが、一旦、別の原因を探ってみることにします。
疑惑３．CPUのバージョン差異もしくはOSのバージョン差異？
OSとCPUのバージョンが違っていることが気になりました。念のため完全に環境を合わせるという意味で、サーバBのOSバージョンをFedora22に戻して、hashrateが変化するかを試してみました。
サーバBのOSバージョンをサーバAと合わせてみた
サーバBのOS再インストールを実施し、サーバAと状態を合わせてみました。
同じ契約で、同じインストレーションを行ったのだから同じ状態になるはず！
OS再インストールとMinergateのAPI再インストールを実施
[root@SERVER_B ~]# rpm -ivh –nodeps minergate-cli.rpm
Preparing… ################################# [100%]
Updating / installing…
1:minergate-cli-6.2_gcc4-1 ################################# [100%]
再度採掘してみます。
[root@SERVER_B ~]# minergate-cli –user XXXXXXXX@gmail.com –xmr 1
[21.11.2017 05:46] [ info] Pool parameters query…
[21.11.2017 05:46] [ info] Loading miners…
[21.11.2017 05:46] [ info] Miners loaded successfully
[21.11.2017 05:46] [ info] Successfully connected to pool: stratum+tcp://xmr.pool.minergate.com:45560. sessio
n_id=”47e45014-5875-478b-af2d-fae72f8557b7″
[21.11.2017 05:46] [ info] New Job: job_id=”d1eef1a8-6f21-428c-bf00-09cc4ba2f3ff” blob=”0606cac2ced0053ce347d
e29ce4ca13374ba92093cfdf0965fb61b2745c41ee3dcb64b8cc4d16900000000f536e5a037dbc530bf55760bfc3ee7fb173e41039e1f2
0c20b72aa39fc4fb6b714″ target=”e4a63d00″
[21.11.2017 05:46] [ info] New difficulty: 1063
XMR hashrate: 8.87 H/s
XMR hashrate: 10.10 H/s
XMR hashrate: 10.48 H/s
なんと、hashrateがサーバA並に上昇しています。/proc/cpuinfoを再度確認してみます。
[root@SERVER_B ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
stepping : 4
microcode : 1064
cpu MHz : 2394.095
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 6
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sy
scall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64
monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_l
m ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt
bogomips : 4788.19
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
cpu MHzの項目が大きく上昇しています。また、OSのバージョンを戻して再インストールしましたが、cpuinfoのそれ以外の部分は変化していませんでした。
再インストール前後の比較結果です。
性能測定（簡易）
[root@SERVER_B ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m6.555s
user 0m5.973s
sys 0m0.127s
一気に早くなっています。。
思い切って性能が高かったサーバAも再インストールしてみた
性能は向上したものの、何故クロック数が倍増したのか理由はわかりませんでした。そこで、調査のために、思い切って順調に稼働していたサーバAも再インストールしてみました。
再インストール後のCPU状態
[root@SERVER_A ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
stepping : 2
microcode : 57
cpu MHz : 2397.132
cache size : 20480 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sy
scall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64
monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdr
and lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm
_llc cqm_occup_llc
bogomips : 4794.26
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
状態を再インストール前後で比較しました。やはりCPUのクロック数（cpu MHz）が倍増しています。flagsはAとA’で変化ありませんでした。
CPU性能評価
[root@SERVER_A ~]# time for ((i=0;++i<1000000;)); do :; done
real 0m3.247s
user 0m3.215s
sys 0m0.029s
当たり前ですが、かなり向上しています。
マイニング実行
[root@SERVER_A ~]# minergate-cli –user XXXXXXXX@gmail.com –xmr 1
[21.11.2017 08:21] [ info] Pool parameters query…
[21.11.2017 08:21] [ info] Loading miners…
[21.11.2017 08:21] [ info] Miners loaded successfully
[21.11.2017 08:21] [ info] Successfully connected to pool: stratum+tcp://xmr.pool.minergate.com:45560. session_id=”d8178728-8636-4141-829a
-c92df60a7b6f”
[21.11.2017 08:21] [ info] New Job: job_id=”9bfed0e0-99ce-4064-be1c-08c093df9ea5″ blob=”0606d18bcfd005b303b48235a868a30c359f223966a28f0f1d
b4d2c176c6c0a09e2798f5dd54a9000000008abdd9842640a5dbbc0f423f378c1fa80bbdf1b00e230eddc26108ee575ff73506″ target=”e4a63d00″
[21.11.2017 08:21] [ info] New difficulty: 1063
XMR hashrate: 33.68 H/s
XMR hashrate: 36.90 H/s
こちらも、hashrateが向上しています。もとのCPUがマイニングと相性が良かったのか、35H/s程度の性能が出ています。
OSによる差異はあるのか？
これまで見てきたように、OSバージョンを合わせるために再インストールを行ったところ、CPUのクロック数が倍増し、結果的に性能も向上しました。おそらくCPUを使い過ぎたことで、知らぬ間に制限がかかってしまったものと推測していますが、OSのバージョンによる差異の検証が出来ていなかったため、再度サーバBのOSをFedora 23にして検証してみました。
サーバBのOSをFedora23(元の状態)にしてみた結果
cpu infoの情報は変化ありませんでした。マイニングのハッシュレートは以下の通り。
[root@48795 ~]# minergate-cli –user XXXXXXXX@gmail.com –xmr 1
[21.11.2017 09:29] [ info] Pool parameters query…
[21.11.2017 09:29] [ info] Loading miners…
[21.11.2017 09:29] [ info] Miners loaded successfully
[21.11.2017 09:29] [ info] Successfully connected to pool: stratum+tcp://xmr.pool.minergate.com:45560. session_id=”db265a86-f2b7-4f04-855b-
523eb027c60a”
[21.11.2017 09:29] [ info] New Job: job_id=”098608b8-ea16-46e2-b0fb-51c7e5b03c75″ blob=”060683abcfd005deca6bc55f9dfd6b899d9964035f341322700
f3ddbc5ff4114453a5981f907e0000000003273b63ec942a52de40be2b155ada6f4352aa024ec61226e48c3bc3061d89a4906″ target=”e4a63d00″
[21.11.2017 09:29] [ info] New difficulty: 1063
XMR hashrate: 8.84 H/s
XMR hashrate: 8.10 H/s
XMR hashrate: 8.50 H/s
XMR hashrate: 8.80 H/s
XMR hashrate: 9.50 H/s
XMR hashrate: 8.90 H/s
XMR hashrate: 7.70 H/s
XMR hashrate: 6.70 H/s
XMR hashrate: 6.96 H/s
XMR hashrate: 9.72 H/s
XMR hashrate: 8.60 H/s
XMR hashrate: 10.80 H/s
XMR hashrate: 7.99 H/s
hashrateはほぼ変換なしか、微妙に減少しているようにみえます。誤差の範囲ですね。
まとめ＆結論
・原因はTime4VPSからの制限と思われる
Time4VPSでCPU100%で稼働させ続けると、いつの間にかクロック数の割当を落とされる場合があるようにみえます。マイニングを行う際にもフル稼働には注意が必要です。余剰リソースでマイニングを行う場合も、常にCPU利用率が100%にならないように時間帯を絞ったり、プロセスのCPU利用率を制限するなど工夫する必要がありそうですね。
参考記事：プロセスの利用CPUに制限をかける方法
・CPUの割当はOSインストール時ではなく、サービス契約時に行われる模様
そのため、OSを再インストールしても割り当てられるCPUは変わりません。当たり前かもしれませんが、マイニングはCPUの種類によって結果が大きく変わるので注意が必要ですね。
・インストールOSのバージョン差異は現時点では影響なさそう
長くなりましたが、追加でわかった情報があれば随時更新していこうと思います。Time4VPSのサービス規約を隅々まで読み込んみようと思います。
（2017/11/21最終更新）
Time4VPSのサーバ契約はこちらから↓
コメントを残す