topic Re: MEMSIZEやSORTSIZEの設定 in SAS Japan Discussion

MEMSIZEやSORTSIZEの設定

sskt — Sat, 04 May 2019 16:43:39 GMT

いつもお世話になっております。

MEMSIZEやSORTSIZEの設定について、例えばメモリ32GBのPCの場合最大値の32Gにすればよいのか、というのがよくわからず悩んでいます。それに関していくつか質問です。

（他にネットで動画を見たり、Rなど他の計算を同時にはさせずSASに専念させるという前提でお願いします。）

・https://communities.sas.com/t5/General-SAS-Programming/SAS-System-Options-Is-MAX-Too-Much/td-p/365856
のfigure5.2を見るとmemsize>realmemsize>sortsize、という理解で正しいのでしょうか。
・また、
https://stackoverflow.com/questions/50632240/making-permanent-changes-to-a-sas-config-file
を見ると32GBのPCでMEMSIZEを32GBにすると問題があるので28GBにしている、というコメントが有るのですがこれは正しいのでしょうか？
・REALMEMSIZEは指定しなくても良いのでしょうか？また、その際REALMEMSIZEの最大値が積んでいるメモリの最大値で、MEMSIZEはそれ以上にすることもできる記述をどこかで見たような気がするのですが正しいのでしょうか？

MEMSIZEを24G, SORTSIZEをMAXにしたところだいぶソートの速度が速まったので可能性を感じています。

詳しい方、ご助言をお願いできないでしょうか。

私はこうして使っています、という情報でも構わないです。よろしくお願いいたします。

追記

CPUCOUNTの設定についてもご意見伺いたいです。

こちらは普通にCPUの実際のコア数に合わせるかACTUALにするか、というところだと思いますが…

（実際のコア数より多くすると逆に遅くなるという記述を以下のページで見つけたので）

http://tetchi-kun.hatenablog.com/entry/2016/11/03/162038

Re: MEMSIZEやSORTSIZEの設定

yu_sas — Tue, 14 May 2019 01:39:26 GMT

1. 認識の通りです。MEMSIZEは使用できる仮想メモリの上限、REALMEMSIZEは使用できる実メモリの量を指定します。

2. 状況次第です。ページングを気にしないのであれば実メモリを超えてもいいですが、一般的には同時起動するSASセッションのMEMSIZEの和が実メモリに収まるようにするのがよいとされています。

3. 基本的には変更しないでもいいと思われます。

4. CPUCOUNTは処理をスレッド化する時の参考情報として使われています。基本的にはコア数が非常に多くても4が適切なことが多いようです。ドキュメントにも書かれていますが、実際のコア数より大きい値にすると処理速度が低下します。

Re: MEMSIZEやSORTSIZEの設定

izumi_sas — Fri, 19 Jul 2019 04:27:42 GMT

PROC SORTのパフォーマンスを真面目に考えるには、以下の要素を考えていくことになります。基本的にはデータ（サイズ、ソートキーなど）に依存した設定になります。私も20年前からこの課題に取り組んでいますが、取り扱うデータは常に変わり、また、システムリソースの利用可能状況も常に変わることも多く、この検討に時間を割くことのROIを常に考える必要があります。また、H/Wの進化、たとえば、ディスクのテクノロジーのイノベーション、メモリのスピード向上・価格低下、などにより、H/Wへの投資の方が劇的なROIを得られることも多いため、そういった選択肢も念頭に入れながら、「パフォーマンス・チューニング」のROIの問題として考えることをお勧めします。

データサイズが大きい場合、ソートの処理時間に影響をする主な要素は、中間データである「ユーティリティファイル」のI/Oの時間すなわち、トータルの読み書き量（回数 x 一回のサイズ）です。これをいかに減らすががポイントになります。

１．OSのメモリ管理やファイルシステムの仕組み

現在主流の仮想メモリ管理の仕組みは、アプリケーションからメモリの使用方法をコントロールしようとすると便利なこともありますが、面倒なこともあります。WindowsとLinuxでも異なるところがあるので、少し知っておくと良いと思います。

ファイルシステムに関しては、仮想環境の現代、昔と大きく異なってしまっているので私にはほとんど知見がありませんが、pagesize=オプションのサイズは、そもそものOSのファイルシステムや物理HDDレベルの、pagesizeと共に検討することも重要です。

２．SASのPROC SORTの内部処理の仕組み

こちらに少し詳細が紹介されています。非表示スライドがあるので閲覧時にはご注意ください。

http://support.sas.com/rnd/papers/sugi30/V9SORT.ppt

PROC SORTの動きは、ものすごくおおざっぱに言うと、

sortsize= オプションに指定した塊ごとに分割して、ソートしてマージして、を何回も繰り返します。その際に使われているのが「ユーティリティ・ファイル」です。つまりその回数が増えるとそれだけ処理時間がかかります。
まるっとメモリだけで処理させるためには、（（ソートキーの長さ）＋（全体のレコード長））X　レコード数、のメモリ量が必要です。なので、ソートキーがレコード長に対して相対的に長いと、想像以上にメモリが必要になります。

３．それら仕組みを念頭にパフォーマンスをコントロールする方法

fullstimerシステムオプションや、PROC SORTのdetailsオプションが役立ちます。出力の詳細はここでは省きますが、以下のような使い方になります。

4    proc sort data=sashelp.class out=sorted details;
5       by name;
6    run;

NOTE: データセットSASHELP.CLASSから19オブザベーションを読み込みました。
mempage=262144 alocsize=34984 isa=262144 osa=262144 xmisa=0
holds=4369 nway=1 sortsize=1073741824 memoryuse=297128.00
keylen=20 reclen=40 dkin=0 inrec=19 outrec=19 yieldobs=0
nruns=1 xcbpage=262144 npages=0 diskuse=0.00

NOTE: データセットWORK.SORTEDは19オブザベーション、5変数です。
NOTE: PROCEDURE SORT処理(合計処理時間):
      処理時間           0.08 秒
      CPU時間            0.07 秒

nrunsが、上記でいうマージの回数です。これが例えば、1より大きな値になっていると、sortsize=を大きくして処理時間の短縮が期待できます。別の見方をすれば、この回数が変わらない範囲であれば、sortsize=を大きくしても、処理時間はほとんど短くならないということです。

また、上述のようにソートキーが長い場合には、タグソートが有効です。

少しでもご参考になれば幸いです。