#MEMめむちょ | Explore Tumblr posts and blogs

tak4hir0 · 5 years ago

Link

この記事は何？この記事はインフラエンジニアが身につけるべき負荷計測コマンドについて解説しています。サーバーやアプリケーションの応答が遅延するなど本来のパフォーマンスを発揮できない時にインフラエンジニアに調査が依頼されることは多いでしょう。大前提として日常的な負荷計測は手動コマンドで行うべきではありません。Mackerel / Zabbix / CloudWatchなどの監視ツールに委ねるべきです。しかし様々な状況や目的から手動で負荷計測したいケースも出てくるでしょう。そのような時に役立つコマンドを解説していきます。なお、当記事はLinuxに関して初歩的なオペレーションを行ったことがある層を前提にしています。そのためtop / ps / uptime / free / df / netstatなどのコマンドは解説しません。初歩的なオペレーションからワンランクアップしたいエンジニアにお薦めです。 vmstat このコマンドは何？ vmstatはシステム全体の負荷を出力するコマンドです。CentOSやDebian / UbuntuやopenSUSEなど多くの環境では標準でvmstatコマンドがインストールされています。細かなプロセス単位のボトルネック特定までは使えませんが、システム全体でどのような負荷が掛かっているかを簡単に知ることができます。 vmstatのインストール方法 CentOSやDebian / UbuntuやopenSUSEではvmstatコマンドは標準でインストールされています。 vmstaの出力 vmstatを実行してみましょう。vmstat 5で5秒間隔のリソースの使用状況を確認できます。 $ vmstat 5 第1引数は何秒間隔で行うかの数値設定ですが、第2引数で実行回数を指定できます。vmstat 5 10で5秒間隔で10回実行します。第2引数を指定しない場合は永続的に実行されます。何もオプションを指定しない場合は1回のみ実行されます。各項目の意味それぞれの項目の意味は以下の通りです。項目意味 r 実行待ち状態にあるプロセス数の合計 b ディスクI/Oやページングなどリソース確保のためにブロックされている状態のプロセス数の合計 swpd 使用中の仮想メモリ（スワップ）量 free 空きメモリ量 buff バッファメモリ量 cache キャッシュメモリ量 si スワップメモリからメモリに展開したデータ量（スワップ・イン） so メモリからスワップメモリに書き込んだデータ量（スワップ・アウト） bi ディスクなどブロックデバイスから読み込んだブロック数 bo ディスクなどブロックデバイスに書き込んだブロック数 in 割り込み回数 cs コンテキスト・スイッチの回数 us CPUのカーネルコード以外の実行に費やした時間の割合 sy CPUのカーネルコードの実行に費やした時間の割合 id CPUのアイドル状態の時間の割合 wa CPUのデータの入出力待ちに費やした時間の割合 st 仮想マシン（ゲストOS）がホストOSに割り当て要求をしたがしたが割り当てられなかったCPU使用率メモリ量の表示単位を変更したいデフォルトではメモリ量がキロバイト単位になっていますので、メガバイトに表示修正したい場合は、vmstat -SMオプションを使うと良いでしょう。 $ vmstat -SM -Sは単位を指定するオプションであり、mは1,000,000、Mは1,048,576、kは1,000、Kは1,024バイト単位となります。オプション指定なしの場合は-SKと同値です。メモリの使用量の情報が見たい dstat -mでメモリの詳細情報を見ることができます。 $ vmstat -m 各ディスク別の統計情報を見たい vmstat -dでディスク別の統計情報を表示します。 $ vmstat -d ディスク全体の統計情報を見たいディスク全体の統計情報を見たい場合はvmstat -Dオプションを使うと良いでしょう。 $ vmstat -D タイムスタンプ情報を付与したい vmstatの出力結果には標準ではタイムスタンプ情報は付与されません。後からいつ出力したかを辿れるようにタイムスタンプ情報を付与したい場合もあるでしょう。タイムスタンプ情報を付与するには以下の2つ方法があります。 1番目の方法はvmstat -tオプションを付与する方法です。一番右側にタイムスタンプが表示されます。あるいはvmstatにパイプで| awk '{print strftime("%F %T ") $0}'を付与すると良いでしょう。 $ vmstat 10 | awk '{print strftime("%F %T ") $0}' sar このコマンドは何？ sarコマンドはvmstatコマンドと似ていますが、このコマンドをインストールするだけで自動的に過去の統計情報を保存してくれます。例えば2日前にどんな負荷がシステムに掛かっていたのかを調査したい場合などsarコマンドはとても役に立ちます。導入方法 sarコマンドの導入にあたってはsysstatというパッケージが必要です。sysstatはOS標準では付属していない場合が多くインストールが必要です。導入方法：CentOSの場合 CentOSの場合は以下のコマンドでインストールできます。 $ sudo sudo yum install sysstat 導入方法：Debian / Ubuntuの場合 Debian / Ubuntuの場合は以下のコマンドでインストールできます。 $ sudo sudo apt install sysstat Debian / Ubuntuの場合はインストール直後はsysstatは無効になっています。/etc/default/sysstatファイルを開き、ENABLED="false"になっている箇所をtrueに変えましょう。 $ sudo vi /etc/default/sysstat ENABLED="true" 導入方法：openSUSEの場合（※注意が必要） openSUSEの場合は以下のコマンドでインストールできます。 $ sudo sudo zypper in sysstat ただ残念なことにopenSUSE15.0や15.1ではsysstatが必要としているgettextパッケージの依存関係に問題があるようです。解決方法1を選択して標準でインストールされているgettext-runtime-miniのパッケージを削除すればsysstatをインストールすることができます。インストール直後インストールした直後は統計ログが蓄積されておらず、コマンドを実行しても以下のようなエラーになります。コーヒーでも飲みながログが溜まるまで待ちましょう。 $ sar /var/log/sa/sa03 を開けません: そのようなファイルやディレクトリはありません 10分間以上待っても統計データが出力されない場合は、導入に問題があった可能性があります。設定を確認しましょう。ちなみにこのsa03というのは日付に対応しています。7月3日ならば/var/log/sa/sa03というファイルに統計情報が蓄積されます。このようにしてデフォルトで28日前までの統計データを辿ることができます。オプションなしでsarを実行した場合、あるいはsar -uを実行した場合は過去のCPU使用率を出力することができます。各項目の意味項目意味 %user CPUのうちカーネル以外の処理に使われた時間の割合 %nice CPUのうちnice値を変更したプロセスに使われた時間の割合 %system CPUのうちカーネル処理に使われた時間の割合 %iowait CPUのうちI/O待ちに使われた時間の割合 %steal CPUのうちゲストOSがホストOSに割り当て要求をしたが割り当てられなかった時間の割合 %idle CPUのうちアイドル状態かつI/Oリクエスト待ちではなかった時間の割合ロードアベレージを表示したいロードアベレージの推移を出力したい場合は、sar -qオプションを使うと良いでしょう。 $ sar -q 項目意味 runq-sz 実行待ちのキューに入っているプロセス数 plist-sz プロセスリストの中のプロセス数とスレッド数 ldavg-1 過去1分間のロードアベレージ ldavg-5 過去5分間のロードアベレージ ldavg-15 過去15分間のロードアベレージメモリの状態を表示したいメモリの推移を出力したい場合は、sar -rオプションを使うと良いでしょう。 $ sar -r 項目意味 kbmemfree 物理メモリ空き容量 kbmemused 物理メモリ使用量 %memused 物理メモリ使用率 kbbuffers バッファに使用されている物理メモリ使用量 kbcached キャッシュに使用されている物理メモリ使用量 kbcommit 現在のワークロードに必要なメモリ容量 %commit 総メモリ容量（RAM+スワップ）に対する現在のワークロードに必要なメモリ容量の比率ディスクI/Oを表示したいディスクI/Oの推移を出力したい場合は、sar -bオプションを使うと良いでしょう。 $ sar -b 項目意味 tps 1秒あたりのI/Oリクエスト数 rtps 1秒あたりの読み込みI/Oリクエスト数 wtps 1秒あたりの書き込みI/Oリクエスト数 bread/s 1秒あたりの読み込みデータ量（ブロック単位） bwrtn/s 1秒あたりの書き込みデータ量（ブロック単位）ネットワークの通信状態を表示したいネットワークの通信状態を表示したい場合は、sar -n DEVオプションを使うと良いでしょう。 $ sar -n DEV 項目意味 IFACE ネットワークインターフェース名 rxpck/s 1秒あたりの総受信パケット数 txpck/s 1秒あたりの総送信パケット数 rxkB/s 1秒あたりの総受信キロバイト数 txkB/s 1秒あたりの総送信キロバイト数 rxcmp/s 1秒あたりの総受信圧縮パケット数 txcmp/s 1秒あたりの総送信圧縮パケット数 rxmcst/s 1秒あたりの総受信マルチキャストパケット数ネットワークの通信エラー状態を表示したい先ほどのコマンドのDEVオプションをEDEVに変えると通信エラーの統計を出力できます。 $ sar -n EDEV 項目意味 IFACE ネットワークインターフェース名 rxerr/s 1秒あたりの総受信エラーパケット数 txerr/s 1秒あたりのパケット送信エラー数 coll/s 1秒あたりのパケット送信衝突数 rxdrop/s 1秒あたりのバッファ領域不足で発生した受信パケットのドロップ数 txdrop/s 1秒あたりのバッファ領域不足で発生した送信パケットのドロップ数 txcarr/s 1秒あたりのパケット送信キャリアエラー数 rxfram/s 1秒あたりのフレーム・アライメント・エラー数 rxfifo/s 1秒あたりの受信パケットのFIFOオーバーランエラー数 txfifo/s 1秒あたりの送信パケットのFIFOオーバーランエラー数過去の情報を取得したい過去の日付の統計結果を得たい場合は、sar -fオプションでログファイルを指定すると過去の日付のデータが確認できます。 $ sar -f /var/log/sa/sa05 トラブルシューティング：ファイルが開けないサーバーの大きな構成変更をした場合に過去のログファイルが以下のエラーで開けないことがあります。 $ sar -f /var/log/sa/sa05 システム動作情報ファイルの形式が正しくありませんこのような場合は以下のコマンドで過去のファイルを開くことができます。 $ sar -f /var/log/sa/sa05 --legacy 過去のデータの蓄積期間を延長したい sarコマンドでデフォルトで記録される期間は28日間ですが、これを延長することもできます。/etc/sysconfig/sysstatに以下のデフォルト値が保存されています。 # Run system activity accounting tool every 10 minutes */10 * * * * root /usr/lib64/sa/sa1 1 1 # 0 * * * * root /usr/lib64/sa/sa1 600 6 & # Generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib64/sa/sa2 -A faust@ip-172-31-29-53:~% sudo cat /etc/sysconfig/sysstat # sysstat-9.0.4 configuration file. # How long to keep log files (in days). # If value is greater than 28, then log files are kept in # multiple directories, one for each month. HISTORY=28 # Compress (using gzip or bzip2) sa and sar files older than (in days): COMPRESSAFTER=31 # Parameters for the system activity data collector (see sadc manual page) # which are used for the generation of log files. SADC_OPTIONS="-S DISK" # Compression program to use. ZIP="bzip2" HISTORY=28となっているのがログの保存期間です。1年間取り続けたいならばこれをHISTORY=365に変えると良いでしょう。なお、HISTORYを28より大きい数字にした場合、データ保存ファイル名が/var/log/sa/sa{DD}であったのが、/var/log/sa/{YYYYMM}/{DD}に自動的に変わります。ディレクトリは自動的に作成されます。 COMPRESSAFTER=31はログを圧縮するデータ経過日数です。ここで指定した日数を経過したログはgzipまたはbzip2で圧縮されます。この圧縮形式を決めているのがZIP="bzip2"オプションです。実行間隔を短くしたい sysstatの記録間隔は/etc/cron.d/sysstatで設定されています。デフォルトでは10分間隔です。また23時53分に前日のログとしてアーカイブされます。 */10 * * * * root /usr/lib64/sa/sa1 1 1 # 0 * * * * root /usr/lib64/sa/sa1 600 6 & # Generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib64/sa/sa2 -A もしこの間隔を5分おきのように短く設定したい場合は、/10となっている部分を/5に変更すると良いでしょう。ただしその分、ログのファイルサイズと負荷は少し上がります。時間帯を指定して統計データを取得したい sarコマンドで時間帯を指定したい場合は、sar -s hh:mm:ss -e hh:mm:ssで指定すると良いでしょう。過去の日付ファイルから時間帯を絞り込むこともできます。 $ sar -s 15:00:00 -e 20:00:00 iostat このコマンドは何？ iostatはディスクI/Oの負荷を計測するのに便利なコマンドです。導入方法 sarコマンドで紹介したsysstatパッケージを導入すると使えるようになります。 iostatコマンドの出力結果 iostatをオプション無しで初回実行した場合、出力結果は以下のようになります。 iostat -xで表示項目を増やすことができます。 iostat -x 5で5秒間隔のI/O負荷が表示されます。 $ iostat -x 5 iostatの注意点として初回実行時はディスクデバイスが有効になってから現在までの累積値が表示されます。リアルタイムなデータを得たいならば2回目以降の結果を元に計測するのが良いでしょう。各項目の意味項目意味 rrqm/s 1秒間あたりのデバイスへマージされた読み込みリクエスト数 wrqm/s 1秒あたりのデバイスへマージされた書き込みリクエスト数 r/s 1秒あたりの読み込みリクエスト数 w/s 1秒あたりの書き込みリクエスト数 rsec/s 1秒あたりの読み込みセクタ数 wsec/s 1秒あたりの書き込みセクタ数 avgrq-sz デバイスへのI/Oリクエストの平均ヘクタサイズ avgpu-sz デバイスへのI/Oリクエストのキューの平均ヘクタサイズ await デバイスへのI/Oリクエストの平均待ち時間（ミリ秒） svctm デバイスへのI/Oリクエストの平均処理時間（ミリ秒） %util デバイスへのI/Oリクエスト時のCPUの使用率 mpstat このコマンドは何？ mpstatコマンドはCPU別の処理負荷を調べるのに便利なコマンドです。導入方法 sarコマンドで紹介したsysstatパッケージを導入すると使えるようになります。 CPU処理の偏りを調べたい mpstatをオプション無しで実行した場合はCPU全体の情報が出力されますが、mpstat -P ALLを指定することでCPU別の処理状況を表示できます。どこかのCPUに処理が偏っていないかを調査できます。以下は1秒間隔でCPUの偏りを調査する例です。 $ mpstat -P ALL 1 dstat このコマンドは何？ dstatはvmstatより詳細に負荷要因になっているプロセスを特定することができます。導入方法：CentOSの場合（※注意が必要） CentOS系の場合は以下のコマンドでインストールできますが、CentOS6の場合は注意が必要です。 $ sudo yum install dstat CentOS6のYumでインストールしたdstatでは、ディスクI/Oが最も多いプロセスをプロセスIDつきで表示する--top-io-advや、ブロックベースで最もディスクI/Oが多いプロセスをプロセスIDつきで表示する--top-bio-advなどのオプションが標準で無効になっています。CentOS7では標準で有効になっていますので問題ありません。 $ sudo dstat -ta --top-io-adv --top-bio-adv dstat: option --top-bio-adv not recognized, try dstat -h for a list of all the options CentOS6の場合の対応策として、ソースコードからインストールした場合はこのオプションが標準で有効になります。 $ git clone https://github.com/dagwieers/dstat $ cd dstat $ make $ sudo make install まあ、--top-io-advや--top-bio-advが使えなくても、そのミニマム版である--top-ioや--top-bioなどで近い結果は得られるのですが、--top-io-advや--top-bio-advが使えた方がプロセスIDが取得できるなど何かと便利です。導入方法：Debian / Ubuntuの場合 Debian / Ubuntuの場合は以下のコマンドでインストールできます。 $ sudo apt install dstat 導入方法：openSUSEの場合 openSUSEの場合は以下のコマンドでインストールできます。 $ sudo zypper in dstat dstatの実行結果オプション無しでdstatを実行した結果は以下の通りです。 $ dstat vmstatとかなり似ていますがカラフルになっていますね。ネットワーク通信やページングに関する情報も表示されています。なお、オプション無しで実行した場合はdstat -cdngyというオプションを指定したのと同値になります。仮にdstat -t（タイムスタンプ情報付与）などでオプションを追加したい場合は、dstat -taなどと-aオプションを付けると、-cdngyをつけるのと同じ意味になります。最もCPU使用率が高いプロセスを特定したい dstat --top-cpu-advを使うと最もCPU使用率が高いプロセスをPIDつきで表示させることができます。なお、この特定結果は一般ユーザー権限では出てこない場合が多くsudoをつけて実行すると良いでしょう。 $ sudo dstat -t --top-cpu-adv 最もメモリ使用量が多いプロセスを表示したい dstat --top-memを使うと最もCPU使用率が高いプロセスを表示させることができます。 $ sudo dstat -t --top-mem 最もディスクI/Oを行っているプロセスを特定したい dstat --top-io-advやdstat --top-bio-advオプションを使うと最もディスクIOを行っているプロセスをPIDつきで表示させることができます。 $ sudo dstat -t --top-io-adv --top-bio-adv 最もOOM Killerの発動要因となりそうなプロセスを特定したい -dstat --top-oomを実行すると最もOOM Killer発動要因となりそうなプロセスが表示されます。 $ sudo dstat -t --top-oom dstatのプラグイン導入方法 dstatのオプションはプラグイン形式で拡張できます。プラグインはPythonで書くことができ、/usr/share/dstat/のディレクトリにdtsta_hogehoge.pyのような名前で入れればオプションで指定できるようになります。多くの場合、標準で以下のプラグインが同梱されています。 lsof このコマンドは何？ある程度原因となるプロセスが絞られてきたらlsofコマンドを実行するのもお薦めです。lsofによって現在プロセスがオープンしているファイル（ファイルディスクリプタ）を調査できます。導入方法：CentOSの場合 CentOSの場合は以下のコマンドでインストールできます。 $ sudo sudo yum install lsof 導入方法：Debian / Ubuntuの場合 Debian / Ubuntuの場合は以下のコマンドでインストールできます。 $ sudo sudo apt install lsof lsofは多くのディストリビューションに標準でインストールされています。プロセスがオープンしているファイル一覧を調べたい lsofはオプションをつけずに実行すると全プロセスの全てのオープンしているファイル一覧を出力してしまいますので、lsof -p ****でプロセスIDを指定するか、プロセス名でgrepするようにしましょう。 $ sudo lsof -p MySQLのプロセスID stress このコマンドは何？ stressコマンドはシステムに対して意図的に負荷を与えることができます。導入方法：CentOSの場合 CentOSの場合は以下のコマンドでインストールできます。 $ sudo sudo yum install stress 導入方法：Debian / Ubuntuの場合 Debian / Ubuntuの場合は以下のコマンドでインストールできます。 $ sudo sudo apt install stress 導入方法：openSUSEの場合残念なことにopenSUSEの標準のリポジトリにはstressパッケージは保管されていません。以下のリンクを参考に環境に合わせたRPMをインストールする必要があります。 software.opensuse.org CPUに負荷を掛けたい stressを使ってCPUに負荷を掛けてみましょう。CPU負荷はstress -c 2 -t 10などのオプションで掛けることができます。-cで指定するのはワーカーの数、-tは実行時間（秒）です。manによると内部的にはsqrt()を実行しています。2コアのサーバーで動かす場合はワーカーは2つに設定すると良いでしょう。 $ stress -c 2 -t 10 dstatでCPU負荷を見てみましょう。CPU使用率が100%になっています。 mpstatで見ても各コアに均等に負荷が掛かっています。メモリに負荷を掛けたい stressでメモリに負荷を掛ける場合はstress --vmオプションを使います。--vmはmalloc()とfree()を繰り返すワーカーの数です。-vm-bytesでメモリ量を指定することができます。デフォルトではメモリの確保と解放を繰り返しますが、--vm-keepオプションでメモリの確保を継続させることができます。今回は1GBのメモリを確保し続けるワーカーを2つ動かしてみましょう。 $ stress --vm 2 --vm-bytes 1G --vm-keep -t 30 それではdstatの結果を見てみましょう。stressによってメモリ負荷が掛かったのが確認できます。トラブルシューティング以下のエラーが出たらメモリが少なってアロケートできず新たにmalloc()を実行するワーカーが追加できません。ほどほどにしましょう。 stress: info: [25009] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd stress: FAIL: [25011] (494) hogvm malloc failed: Cannot allocate memory stress: FAIL: [25009] (394) <-- worker 25011 returned error 1 stress: WARN: [25009] (396) now reaping child worker processes stress: FAIL: [25009] (400) kill error: No such process stress: FAIL: [25010] (494) hogvm malloc failed: Cannot allocate memory stress: FAIL: [25009] (394) <-- worker 25010 returned error 1 stress: WARN: [25009] (396) now reaping child worker processes stress: FAIL: [25009] (400) kill error: No such process stress: FAIL: [25009] (451) failed run completed in 0s 応用編へ向けて今回紹介しきれなかったコマンドは応用編にて書いていきます。

#はてな村定点観測所

0 notes

curationmonkey · 4 years ago

Text

三井住友カードで投資信託が買えるように！（還元率0.5％Vポイント）2021年2月からSBI証券で

fromhttps://dopingconsomme.blogspot.com/2020/07/mitsuisumitomo.html https://www.pinterest.jp/search/pins/?q=三井住友カードで投資信託が買えるように！（還元率0.5％Vポイント）2021年2月からSBI証券で https://twitter.com/search?q=三井住友カードで投資信託が買えるように！（還元率0.5％Vポイント）2021年2月からSBI証券で https://bing.com/search?q=三井住友カードで投資信託が買えるように！（還元率0.5％Vポイント）2021年2月からSBI証券で https://www.google.com/search?q=三井住友カードで投資信託が買えるように！（還元率0.5％Vポイント）2021年2月からSBI証券で pin,twi,bing,google,au,y!jp,y!us, B!,DDG,皆声,

株式会社SBI証券（代表取締役社長：髙村正人、以下「SBI証券」）と三井住友カード株式会社（代表取締役社長：大西幸彦、以下「三井住友カード」）は、2020年7月28日（火）付で、個人向け資産運用サービスにおける業務提携（以下「本提携」）に関する基本合意書を締結しましたので、お知らせします。

1. 本提携の目的

SBI証券と三井住友カードのそれぞれが属するSBIグループとSMBCグループは、本年4月28日（火）に発表した戦略的資本・業務提携に関する基本合意に基づき、両グループの各種領域における強みを活かした連携強化に向けて協議を進めています。今般、若年層および投資初心者への中長期的な資産形成の支援を目的として、SBI証券と三井住友カードによる新たな個人向け資産運用サービスの提供に関する基本合意に至りました。　SBI証券は、資産運用サービスにおいて、三井住友カードのクレジットカードなどを活用してサービスの拡充を目指すとともに、三井住友カードのお客さま、特に若年層および投資初心者層のお客さまにSBI証券の金融商品・サービスを提供することで、顧客基盤の拡大を図っていきます。三井住友カードは、SBI証券と金融商品仲介サービスで提携します。クレジットカード決済による投信積立サービスの提供など、資産運用と決済を組み合わせ、お客さまの多様化するニーズに的確に対応していきます。また、資産運用サービスについては、本提携に加え、SMBC日興証券をはじめとするグループ各社との連携を高度化するとともに、グループ外のプレイヤーとの幅広い協働を通じて、新たな収益の柱として成長させていきます。

2. 本提携の内容

SBI証券と三井住友カードは、2021年2月以降、順次以下のサービスの開始を予定しています。＜三井住友カード経由でSBI証券総合口座を開設されるお客さま（金融商品仲介業）　通常どおり、SBI証券が提供する株式、投資信託などの金融商品や各種サービスを利用可能です。さらに、①～④のサービスもご利用いただけるようになります。

①SBI証券の投信積立サービスにおける三井住友カードのクレジットカード決済

（決済金額の0.5％分のVポイント※１を付与）

②三井住友カードアプリ上でのSBI証券総合口座情報の表示

③Vポイント1ポイント＝1円として、SBI証券の投資信託の買付ができる「Vポイント投資」

④投資信託保有残高に応じてVポイントを付与※2

＜既にSBI証券総合口座を開設済みのお客さまおよび三井住友カード経由以外で今後SBI証券総合口座を開設されるお客さま＞　SBI証券が提供する株式、投資信託などの金融商品や各種サービスをすべて利用可能です。さらに、上記①②のサービスをご利用いただけるようになります。さらに、今後、スマートフォンの活用を中心として、両社の強みを活かした新サービスを検討していきます。　オンライン総合証券として証券総合口座数、預かり資産残高、株式委託個人売買代金シェアにおいてネット証券No.1※3の地位を誇るSBI証券とキャッシュレスリーディングカンパニーである三井住友カードの提携により、両社のお客さまの一層の利便性向上を図ることが可能となり、これまで以上に若年層、投資初心者層のお客さまに両社のサービスをご利用いただけるようになるものと期待しています。 ※1 Vポイントは2020年6月1日（月）よりワールドプレゼントポイントからリニューアルした、三井住友カードが管理・運営するSMBC グループ共通のポイントです。三井住友銀行と三井住友カードのそれぞれの各種取引でポイントが貯まります。それぞれで貯まった V ポイントは、おまとめ手続きを行うことで合算して使うことができます。ポイント累積数に応じて希望の景品との交換や、銀行の振込手数料割引、他社ポイントへの移行ができます。三井住友カードの場合、通常、毎月のカードご利用金額の合計200円（含む消費税など）ごとに1ポイント（1円相当）を付与いたします。 Vポイントの詳細はこちらをご覧ください。 https://www.smbc-card.com/mem/wp/about_vp.jsp ※2 投資信託保有残高に応じてTポイントが貯まる「投信マイレージサービス」との併用はできません。 ※3 比較対象範囲は、主要ネット証券5社との比較となります。「主要ネット証券」とは、口座開設数上位5社のSBI証券、楽天証券、マネックス証券、松井証券、auカブコム証券（順不同）を指します。（2020年7月28日現在、SBI証券調べ）

（http://www.sbigroup.co.jp/news/pr/2020/0728_12043.htmlより）

　なんか楽天みたいなことがしたいんでしょうね。しかし経済圏の完成度では楽天のほうが一枚上手なかんじがしますわ。

Vポイント

有効期限：取得付きから2年間

使い道

iDにチャージできるので普段使いでIDを使っている人はIDがよいでしょう。

ID利用者でない人は他社ポイントに交換するといいでしょう。楽天ポイント、ヨドバシゴールドポイント、ドコモのdポイント、ビッグポイントなどは1ポイント＝移行先の1ポイントとして交換できます。

楽天ポイントに交換すればそれでまた投資信託が買えますね。

終わりに

って、来年2月か～い！先が長いよ！

DopingConsomme

#IFTTT #DopingConsommeBlog #link #July 29 #2020 at 08:30PM

0 notes

kkkeag · 7 years ago

Text

2017/11/21 ツクモでPC買った

去年あたりから2012年に買ったデスクトップPCの買い替え視野に入れて、つい最近ようやく買った。今のもまだ生きてるしぜんぜん使えるのだけど、たまに突然ブルースクリーンも吐かずに落ちたりマザボからBeep音なったりしたりしてちょっと不安だった。ストレージも入れ替えたかったし。

GWにZOTACのGTX1070Miniを買ったのでそれを使いまわしたい

できればATXの電源もあるからそれも使いまわしたい

ミニタワーかmini-itx、どちらかと言えばmini-itxを触ってみたい

って考えたときに

BTOでオンボードのミニタワー買って電源とグラボ載せ替える

BTOで普通にゲーミングPC買ってグラボ売る

自作で組む

って選択肢が湧いてきて、しばらく考え込んでた。

結論からいうとどれにも当てはまらなくて、Mini-ITXの組み立て処分品が売られていたのでそれを買った。 11月の3連休にツクモ本館にふらっと足運んだらそいつがいて。

ROG STRIX Z270I GAMING

電源

SST-SX600G

CPU

Core i7 7700

MEM

crucial W4U2400CM-8G *2

ストレージ

3TBHDD + WD Black PCIe WDS512G1X0C

ケース

AS Enclosure RS01

GPU

GF-GTX1070-E8GB/OC/SHORT

で170kくらいだった気がする。 GTX1070Miniを自前で使いまわしたい旨を伝えたら元々乗っていた1070外して割引いてくれた上に、今持ってるボードがケースに合うかどうかまで測ってくれて本当に助かった。 ZOTACのグラボはバックボードが挟まるためにCPUクーラーとぎりぎり干渉するかもしれないこと、幅があるために側面のケース板を止めるときにすこし押し込んでやる必要があるアドバイスを頂いた上で購入。 130k強��らいになった。

帰って早速グラボ入れ替えようとして蓋開けてみたらその密度におったまげてしまった。ケースがminiITXの中でも小さいものとはいえ隙間なくパーツが詰められていて、マザボに手をのばすのも一苦労。店員さんのアドバイスはまさに完璧で、バックボードはCPUクーラーに触れるか触れないかといった具合。蓋を閉める際もすこしケーブルを押す形になったがなんとか入った。それよりも既存で使ってる2.5インチSSDのケース引っ越しが大変で、SATAのケーブルをマザボに刺すのが特に苦労した。狭すぎる。ケースの板が上左右全部はずせる仕様のおかげでなんとかなった感じ。いいケースだ。 SSDはHDDと同じところに入れたんだけど、調べると底に置いても良かったらしい。でも底の吸気を考えて塞ぐのはやめた。

この密度よ。 pic.twitter.com/aOSFR1og0F

— い (@UVB_76) November 4, 2017

二枚目のグラボのバックボードにぎりぎり接するか接しないかってところにある銀の出っ張りが例のCPUクーラーのネジ。ゲームやる前はそこまで性能差を感じないと思ってたんだけど、流石に5年経ってたらしい、CPUの違いだけでここまで変わるのかって感心してしまった。前のi7 3770のときは処理落ち入りそうなところも、画質設定を今まで以上に上げてもFPS落ちなくて、凄い。ただ、音がすこし、熱がわりと頑張ってる感出してて、ゲームやってるとケースがほんのり熱い。そのうちちゃんと測りたい。音に関しては穴だらけのケースに求めるものではないとして諦めてた。今はケース底上げして底面開けてあげたほうが良いのかなとか考えているところ。

あとマザボのBluetoothの感度がキーボード入力に支障きたすくらいひどかったんだけど、付属のアンテナ張ったら快適になった。あれWifiだけじゃないのね…

というわけでいい時期での買い物だったと思う。ツクモの店員さんマジありがとう。メモリもストレージも増えていい感じになったので、ようやく仮想やら色々いじっていきたい。ただ予算はオーバーしてるからしばらく節約したい…ということで、早速帰省はシーズン外して往復3万で抑えることとなった。

と言うわけでだいぶスッキリした pic.twitter.com/nmvjT9rgn2

— い (@UVB_76) November 5, 2017

0 notes

awsexchage · 8 years ago

Photo

小ネタ道場一本勝負〜 Ubuntu xenial で Elasticsearch が Cannot allocate memory で起動しない場合〜 http://ift.tt/2r7RCVb

試した環境

インストール直後

ということで、技あり

有難うございました

試した環境

ubuntu@ubuntu-xenial:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" ubuntu@ubuntu-xenial:~$ free total used free shared buff/cache available Mem: 1015992 49948 397164 3440 568880 770376 Swap: 0 0 0 ubuntu@ubuntu-xenial:~$ curl localhost:9200/ { "name" : "u0y-s7V", "cluster_name" : "elasticsearch", "cluster_uuid" : "p20emC22SyG96ziu0qwl5w", "version" : { "number" : "5.3.2", "build_hash" : "3068195", "build_date" : "2017-04-24T16:15:59.481Z", "build_snapshot" : false, "lucene_version" : "6.4.2" }, "tagline" : "You Know, for Search" }

インストール直後

deb パッケージをダウンロードしてインストール後に確認してみると…

ubuntu@ubuntu-xenial:~$ sudo service elasticsearch status ● elasticsearch.service - Elasticsearch Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-05-02 23:48:36 UTC; 4s ago Docs: http://www.elastic.co Process: 10100 ExecStart=/usr/share/elasticsearch/bin/elasticsearch -p ${PID_DIR}/elasticsearch.pid --quiet -Edefault.path.logs=${LOG_DIR} -Edefault.path.data=${DATA_DIR} -Edefault.path.conf=${CONF_DIR} (code=exited, status=1/FAILURE) Process: 10097 ExecStartPre=/usr/share/elasticsearch/bin/elasticsearch-systemd-pre-exec (code=exited, status=0/SUCCESS) Main PID: 10100 (code=exited, status=1/FAILURE) May 02 23:48:36 ubuntu-xenial systemd[1]: Started Elasticsearch. May 02 23:48:36 ubuntu-xenial elasticsearch[10100]: OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000000008a660000, 1973026816, 0) failed; error='Cannot allocate memory' (errno=12) May 02 23:48:36 ubuntu-xenial elasticsearch[10100]: # May 02 23:48:36 ubuntu-xenial elasticsearch[10100]: # There is insufficient memory for the Java Runtime Environment to continue. May 02 23:48:36 ubuntu-xenial elasticsearch[10100]: # Native memory allocation (mmap) failed to map 1973026816 bytes for committing reserved memory. May 02 23:48:36 ubuntu-xenial elasticsearch[10100]: # An error report file with more information is saved as: May 02 23:48:36 ubuntu-xenial elasticsearch[10100]: # /tmp/hs_err_pid10100.log May 02 23:48:36 ubuntu-xenial systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE May 02 23:48:36 ubuntu-xenial systemd[1]: elasticsearch.service: Unit entered failed state. May 02 23:48:36 ubuntu-xenial systemd[1]: elasticsearch.service: Failed with result 'exit-code'.

ふむ。

ということで、技あり

/etc/elasticsearch/jvm.options で JVM オプションを修正してヒープサイズを修正する。

root@ubuntu-xenial:/etc/elasticsearch# diff -u jvm.options.bk jvm.options --- jvm.options.bk 2017-05-02 23:51:22.295369994 +0000 +++ jvm.options 2017-05-02 23:51:36.788119994 +0000 @@ -19,8 +19,8 @@ # Xms represents the initial size of total heap space # Xmx represents the maximum size of total heap space --Xms2g --Xmx2g +-Xms512m +-Xmx512m ################################################################ ## Expert settings

実際にどの程度の値に設定すれば良いのかについては、以下のドキュメントに記載されている。

Set JVM heap size via jvm.options | Elasticsearch Reference [5.4] | Elastic

http://ift.tt/2ogCSAJ

www.elastic.co

ざっくり要約すると…（Powered by Google 翻訳）

minimum heap size (Xms) と maximum heap size (Xmx) は同じ値にしましょう

Elasticsearch で使用可能なヒープサイズが多いほど、キャッシュに使用できるメモリが増えるばい

ただし、ヒープサイズを割り当て過ぎると長い GC が発生する可能性があることに注意しませう

maximum heap size (Xmx) は物理メモリの 50% を超えないようにして、カーネルファイルシステムのキャッシュ用に十分な物理メモリが残っていることを確認しませう

maximum heap size (Xmx) を 32GB に近い値に設定しない方が良いです（超意訳ですいません … compressed oops の絡み）

じゃあ、Xmx の最大値だと 26GB 〜 30GB くらいにしておくと安全でせう（超意訳ですいません）

がっつりメモリがある場合でも、メモリの割り当てには注意しましょうってことですな。