常連

### 実現したいこと
RHEL環境でシェルを稼働させた際の性能監視方法を確立させたいです。
具体的にはメモリ使用率の確認観点を明確にしたいです。
今まではvmstatで出力されるfreeの消費状況を確認しており、
freeの推移が水平であることを以てメモリリークの可能性は無いと判断しておりました。
ですがこれで十分なのかで悩んでおります。

例えばJavaの場合、jconsole等によってヒープ領域のYoungメモリ内のEdenを監視することができると思います。
同じようにRHEL上のシェルでも同レベルの監視は可能かどうか、そしてそこまでする必要があるのかを判断させていただきたいです。

※ 申し訳ありませんがメモリ関連に詳しくないため、記載にご不明点がありましたらご指摘いただけますと幸いです。

### 前提
RHEL8.3上で常駐のシェルを稼働し、その際のメモリ消費を監視します。
RHELはCUIのみの環境です。（GUI非対応）

### 試したこと
現状ではvmstatをバックグラウンドで実行し、出力をテキストファイルにリダイレクトしてfreeの消費量を監視しています。



RHEL上で稼働するシェルのメモリ性能評価

### 実現したいこと

VB.Netで作成したアプリのメモリリークを解決したい。
・タスクマネージャー上のワーキングセットを肥大化していくためこれを抑制、もしくは一定期間で破棄を行いたい。

### 前提
・.Net Framework 4.5 をターゲットフレームワークとしています。
・Windowsサービスとして構成し、処理クラスをサービスからインスタンス化して実行しています。
・処理クラスはThreading.Timerを使ってファイル監視を行い、ファイルが存在した場合に内容を読み込んでODBCによりDB更新を行っています。

### 発生している問題・エラーメッセージ
現象としてはファイル（20KB～78KB）を処理するにともなってタスマネージャー上のワーキングセットが肥大化しており、これがサーバー実行上3日間ぐらいの稼働（原則24時間稼働）で10GBを超えることから何とかリークを解消したいという思いです。
開発端末（Windows10）では完全無風状態が続くと、タスクマネージャー上のワーキングセットが減少しますが、顧客環境のWindowsサーバー上では減少しているのかいまいち把握できないのと、もっと早いタイミングで減少させたいという思いです。

【質問事項】
先輩方にお聞きしたいのが、VisualStudio2019のデバッグでメモリの状況を確認しているとプロセスメモリ（MB）が368MB以上にも係わらずスナップショットを取るとヒープサイズは1Mとなっています。
このプロセスメモリの内容調査をしたい場合どのような手法があるでしょうか。
![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-09-03/4e336342-4e0d-488e-93d8-745a0f5227ee.png)

### 該当のソースコード

```VB.Net

### 試したこと
・Fileへのアクセス時のUsing使用
・ODBCオブジェクトUsing使用
・内部変数の破棄
・内部のStringクラスの使用をやめる検討
・内部クラスでDisposeを実装してクラス変数のDictionaryのすべてのキーのRemoveを実行する。
・関数で使用している内部変数をFinallyブロックを作成して破棄　等...
```

###追記
WinDBGを使用してダンプの解析を行ってみた内容です。
・ヒープに割り当たっているメモリ（heap -s 0）の予約、コミットはタスクマネージャーと近しい数値が見えました。
・割り当てされたオブジェクトサイズごとの一覧（heap -stat -h 0）ではやはり小さい数字の合計しか取れませんでした。
・リークしたヒープ（heap -l）を取ると確かに大量にCountのメモリが検出されますがトータルサイズですと、タスクマネージャーのワーキングセットの大きさにはならず。

VB.Netで作成したアプリのメモリリークを解決したい

### 前提・実現したいこと

C言語初心者で配列の勉強をしています。
Visual Studio 2019にて”デバッグの開始”を行ったところ
下記エラーが発生します。
エラーを解決する方法と、このようなエラーを発生させないためには
なにを勉強すればいいか教えて頂けないでしょうか。

### 発生している問題・エラーメッセージ

Run-Time Check Failure #2 - Stack around the variable 'a' was corrupted.

### 該当のソースコード

```ここに言語名を入力
#include<stdio.h>

#define N 20	/*要素の数*/

int main(void) {
	int a[N] = {1,5,4,9,23,16,2,13};
	int i, temp, flag;

	do
	{
		flag = 0;
		for (i = 0; i < N + 1; i++)
		{
			if (a[i] > a[i + 1])
			{
				temp = a[i];
				a[i] = a[i + 1];
				a[i + 1] = temp;
				flag = 1;

			}
		}
	
	} while (flag == 1);

	for (i = 0; i < N; i++)
	{
		printf("%d	", a[i]);
		printf("\n");
	}

	return 0;
	   
}

```

### 試したこと

webで調べたところ、スタック破壊が起きているような記載を見かけました。
そこで、defineのNを大きくしてみましたが（10とか）、解決しませんでした。
ちなみにpaizaのwebエディタで同様の記述を行ったところ、エラーが
出なかったのも腑に落ちず、VS2019の操作方法に誤りがあるのかも疑っています。


### 補足情報（FW/ツールのバージョンなど）

Visual Studio 2019

【C言語/初心者】スタック破壊エラーの解決法について

## テーマ、知りたいこと
HDD、SSD、RAMに関することで３つほど疑問があります。

昨今、当たり前のようにSSD搭載されていますが、
仮想メモリを割り当てたままだと、２〜３年ほどでの故障を多く見ています。

仮想メモリを多く使うアプリケーションを使用しており、
仮想メモリの話をする前に、限界までメモリを積むべきだと思いますが、
２台似たような条件のPCがあり、２台とも似たような構成です。

ここでSSDに加えてHDDを取り付けて、HDD側に仮想メモリを全振り
(ノートパソコン、M２スロットはSSD、SATA2.５スロットはHDD）
を試みましたが、pagefile.sysが割り当てられたり、割り当てられなかったり
割り当てられても使用されておらず、メモリエラー系のトラブルが発生します。

仮想メモリを内蔵SSDに戻すと正常に。
あえて安いSSDを使い潰すつもりで、SSDをつけて仮想メモリを割ってみるも...同様にしばらくしてエラー。。
1台はWindows10、1台はWindows11ですが、変化なく。。

当然、本体の上限のRAM【１６GB】まで増設しています。
３２GBも積めるようですが、運であることや、DDR3のノート用１６GB２枚は高すぎて
1台はインテル7世代CPUなので、買い換えるべきかと、諦めています。

なにかいい方法はないでしょうか？

話が脱線しましたが、HDDのパソコン、と一括りでいっても
クリーンインストールしても、立ち上がるのに10分、ブラウザ起動に5分など
異常に遅いPC

SSD並み？とは言わないものの、そんなに遅くないHDD
使っててストレスの感じない状態で、SSDに変えなくてもいいかな？と思うほど

いずれも、CrystalDiskInfoで見る限り、正常です。

これは一体どんな差があるのでしょうか？
回転数、キャッシュ、プラッタの密度、2.5/3.5インチの違い、SATA転送速度...などでしょうか？

私の使っているMacBook Pro(2019,16インチ,Corei9,64GB RAM,8TBSSD)
より速いHDD機もあるぐらいです。

さらに余談です、わかる人がいましたら教えてください。
iMacのFusion Driveに、WindowsとMacを両立させたいのですが、
Windows側には何をしても、Fusion Driveのメリットは得れないのでしょうか？

Fusion Driveを分離させて、64GBずつに切ってそれぞれに入れて、1TBHDDはファイル置き場...ぐらいが妥当でしょうか？
こちらも、あえてFusion分離でHDDにインストールすると、起動に20分...

こちらはiMac 2015 21.5インチモデルですが、分解してSSD増設...の価値があるのかを考えています。
使い方的に多分、Fusion Driveを分離させてWindowsとMac各60GBで足りるかもしれません。

私がVMwareのデータを置いている8TB HDDは2台同時起動でも1分ほどで立ち上がり、動作は快適です。
（さらにBitLocker暗号化やクラウド同期もバックグラウンド作動しています。USB3.0での接続）

最後ですがもう１つ余談です。

会社にiMac 2017 21.5インチが1台余っており、
こちらも自由に使っていいとのこと、
CPUはCore i5-7400、RAMは8GB、HDDは1TBという構成ですが、
クリーンインストールから起動に20分近く、、
もちろんCrystalDiskinfoは正常
外付けSSDにインストールするが、最初は爆速ですが今後は不定期にプチフリ、、

増設すると、CPUはi7-7700K、RAMは64GB、SSDに交換可能...なようですが、
やる価値はありますでしょうか？
自作PCやノートパソコンのCPU、RAM、HDD等の増設経験はありますが...iMacはややこしそうで
費用対効果を知りたい次第です。

2017は１箇所フロントガラスが欠けており、コーティングが全体的にはげて見にくく、売価は見込めません。
お金は会社から出るので、価値がある場合は行おうと思います。

追記...
会社の不用物としてMacBook Pro 2010も出てきました。
Core2Duo P8800 4GB RAM、320GB HDD、
バッテリーが膨れ上がっており、クリックが押せないため
とりあえず流石に純正品電池はもうなく、サードパーティを注文し運用
こちらはそんなに部品が高くなく、交換が容易なので
16GB RAM、128GB SSDでいこうと思いますが...
無理やりMontereyが動くところまでは達したものの、
これはもうお役御免ですかね。

すごいたくさんの初歩的な質問になりますが、どうかご教示いただけますと幸いです。

よろしくお願いします。

## 背景、状況
業務でPython開発をしており、
今会社で余っており、好きに使っていいと与えられている
パソコンを、Pythonで開発した自動プログラムやサーバー代わりの常時起動用にいくつかしたく、
なるべくお金をかけずに、高速に動くようにしたい次第です。

HDD、何故遅いものと速いものがあるのか、そして仮想メモリ、増設すべきかしないか？

C言語で作成したループで同じ処理を行い続けるプログラムを長時間動かしていると、psコマンドのVSZとRSSが漸増していくのですが、この場合メモリリークしていると考えるのが妥当でしょうか。

Valgrindで処理を動かしてもメモリリークは見つからないのですが、psコマンドで見るとメモリ使用量が増えています。数分おきに一定程度ずつ増えるわけでもなく、何らかのタイミングで増えているようです。

こういった場合、Valgrindを使用する以外にメモリリークを調査する方法はあるのでしょうか。目視で確認していく形でしょうか。

漠然とした質問で申し訳ありませんが、ご教示いただけますと幸いです。よろしくお願いいたします。

psコマンドでメモリ使用量が増えている場合はメモリリークしているのか

Google Colab.の無料GPUでプログラムを実行したところ、メモリ（RAM:12.72GB）が一気に消費されてしまいます。
原因と対策についてご教授いただきたいです。

・コード
```Python
#サマータイム期間外ならデータの時刻を1時間早くする（=サマータイムの時間にあわせる）
import time
new = []
new_append = new.append
elapsed_time = 0
t1 = time.time()

def Summer():
  for i,x in enumerate(data["summer"]):
      if x == "EST": # ESTなら1時間データを早くする 
          new_append(data.iloc[i,0:1]+timedelta(hours=-1))
          new[-1]["time"]=str(new[-1]["time"]) #上で型がdatetime64になるので戻す
      else:          # EDTならそのまま
          new_append(data.iloc[i,0:1])
      if i%20000==0: #進捗確認用に20000データ毎に出力
          print(i)

Summer()
new = pd.DataFrame(new) #【※】ここでメモリ消費が急増
data.iloc[:,0:1] = new["time"]

t2 = time.time()     # 処理後の時刻
elapsed_time = t2-t1 # 経過時間
print(f"経過時間：{elapsed_time}") # 経過時間を表示
```
inputは以下のようなデータです。
・data（長さは実際は400,000程度）
||time|summer|
|:--|:--:|--:|
|0|2019-10-10 06:02:00|EDT|
|1|2020-11-23 06:02:00|EST|

コードの【※】の箇所で120s程度の時間がかかり、メモリ消費が著しく増大します。
dataもnewのバイト数を調べてみましたが、数MB程度でデータ長が原因ではないのかな？と考えております。
（ちなみに、inputの長さが1,000,000を超えたものにすると、クラッシュします・・・）


・原因の確認をしたくて試したこと
１. 実行後に別のセルにて、先ほど宣言した変数をdelで消去しましたが、【※】で増大した分のメモリは解放されませんでした。
    →やはり、変数のデータの長さは関係なさそう？
２. 下記のように一旦別の変数をかませてみてもメモリの増大量はほぼ変わりませんでした。
　  下記のコードの場合、2行目のnew1 = pd.DataFrame(new1)でメモリが増大します。
```Python
new1 = new.copy()
new1 = pd.DataFrame(new1)
new  = data.iloc[:,0:1]
```

メモリが一気に数GB食われる原因と対策

お世話になります。

常駐プロセスとなるプログラムを稼働させ続けているのですが、
気になっている点が2点あります。
起動引数は以下を設定しています。

```java
-Xms128m
-Xmx128m
-Xmn64m
-XX:MetaspaceSize=64m
-XX:MaxMetaspaceSize=128m
```

①S1領域
1回目のFGCが発生するまではかなりの時間がかかり、S1領域がずっと100%でした。
しかし、1度FGCが発生するとS1が0になり、その後FGCが頻発するようになりました。
これはXmxの値が小さいことが原因でしょうか？
※メモリ使用率については下記参照願います

②引数設定
プロセスを常駐させておくと、
GCは発生しているものの、継続的なメモリ上昇が見受けられ、
メモリリークのようなことが起きているように思われます。
これは引数設定に問題があるのでしょうか？
設定内容的には200m程度で収まる認識だったのですが、
タスクマネージャーから見ると240mに到達しており、現在も増えている状態です。

指摘事項などありましたら、
ご教示の程宜しくお願い致します。


jstatでメモリ使用率を表示したところ以下のようになりました。（抜粋）

```ここに言語を入力
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT
  0.00 100.00  62.50  99.84  96.52  90.35    170    1.020     0    0.000    10    0.049    1.068
  0.00 100.00  70.31  99.84  96.52  90.35    170    1.020     0    0.000    10    0.049    1.068
  0.00 100.00  79.69  99.84  96.52  90.35    170    1.020     0    0.000    10    0.049    1.068
  0.00 100.00  89.06  99.84  96.52  90.35    170    1.020     0    0.000    10    0.049    1.068
  0.00 100.00   3.08  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  13.85  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  21.54  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  29.23  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  38.46  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  47.69  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  55.38  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  64.62  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  72.31  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  81.54  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00  90.77  99.93  96.52  90.35    171    1.026     0    0.000    12    0.056    1.082
  0.00 100.00   5.41 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00 100.00  21.62 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00 100.00  37.84 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00 100.00  54.05 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00 100.00  64.86 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00 100.00  81.08 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00 100.00  97.30 100.00  96.52  90.35    172    1.051     0    0.000    12    0.056    1.107
  0.00   0.00   7.35  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  16.18  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  25.00  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  33.82  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  41.18  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  48.53  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  57.35  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300
  0.00   0.00  66.18  90.93  96.09  89.89    173    1.068     1    0.176    12    0.056    1.300

```

```ここに言語を
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT
  0.00   0.00  91.94  98.74  96.25  90.07    223    1.681    23    3.501    32    0.137    5.319
  0.00   0.00   4.84  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  11.29  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  19.35  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  29.03  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  38.71  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  46.77  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  54.84  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  64.52  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  72.58  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  82.26  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  88.71  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00  96.77  99.03  96.10  89.90    224    1.701    24    3.658    32    0.137    5.496
  0.00   0.00   8.06  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  16.13  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  22.58  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  32.26  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  40.32  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  48.39  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  58.06  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  66.13  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  75.81  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  83.87  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00  93.55  99.39  96.20  90.01    225    1.722    25    3.804    32    0.137    5.663
  0.00   0.00   3.23  99.74  96.27  90.09    226    1.741    26    3.950    32    0.137    5.829
  0.00   0.00  11.29  99.74  96.27  90.09    226    1.741    26    3.950    32    0.137    5.829
  0.00   0.00  20.97  99.74  96.27  90.09    226    1.741    26    3.950    32    0.137    5.829
  0.00   0.00  27.42  99.74  96.27  90.09    226    1.741    26    3.950    32    0.137    5.829
  0.00   0.00  37.10  99.74  96.27  90.09    226    1.741    26    3.950    32    0.137    5.829
  0.00   0.00  46.77  99.74  96.27  90.09    226    1.741    26    3.950    32    0.137    5.829
```

jconsole結果
![イメージ説明](28f24c8468ef4e225055f79dbacf66e7.png)

![イメージ説明](601f08043d6839f8a056907fd8e97746.png)

![イメージ説明](eaac6f64d8293a63501735a9d3690768.png)

FGC頻発例（1度目までは時間がかかったが、次回以降で間隔が短い）
![イメージ説明](a8bd1ef28782f82c6a1832fb3c6d6f6c.png)

![イメージ説明](3425a67898413dc8de456cc2d55e6bba.png)

【JVM】VM引数で指定するメモリの目安について知りたいです。

# 前提
Java、AWS等を学習している者です。
SpringBootで作成したwarを、EC2にインストールしたTomcatに載せています。
catalina.outに下記の様なエラーが出ていて、サーバーにリクエストできなくなっていました。

# 発生しているエラー
```
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(~略~) failed; error='Not enough space' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 16384 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /tmp/hs_err_pid~略~.log
```

# 考えていること
エラー文を読むと、メモリが足りなくなって落ちていることがわかりました。
根本原因は引き続き調査するとして、対処療法的な？回避策として、下記の様な記事がありました。

[システム監視における再起動の役割](https://www.sherpasuite.net/column/management/193/)

曰く、**再起動は“トラブル予防の一環”** とのこと。
毎日cronで再起動すれば、上記のエラーも解消されそうな気がしていて、試してみるつもりです。
このように定期的に再起動することは、実際の開発現場でもあることなのでしょうか？


また、更に調べると、

[Tomcatのサービスが異常終了していたら起動コマンドを実行するスクリプト](https://hacknote.jp/archives/295/)

cronで毎分、Tomcatのステータスをチェックし、異常時には再起動するようです。
こういったことも、実際の開発現場であることでしょうか？

個人的には、まずはAPサーバーを落ちないように設計することが第一と考え、
その保険として上記のような保険があると良いのかなと思いました。

しかし私は経験に乏しく、
「これって本当に対処法としてありなのか？」
「現実としてやっている開発現場はあるのか？」
といった疑問があり、質問させていただきました。

何卒よろしくお願い致します。