常連

お世話になります。

常駐プロセスとなるプログラムを稼働させ続けているのですが、
気になっている点が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引数で指定するメモリの目安について知りたいです。

### 前提・実現したいこと

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言語/初心者】スタック破壊エラーの解決法について

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

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

Windows7でパフォーマンスモニタを利用してメモリリークの調査についての問合せを受けていますが知識が乏しくよく分かっていません。
どなたかご教授頂けないでしょうか。

知りたいことは、タスクマネージャのパフォーマンスタブにある「キャッシュ済み」と「空きメモリ」が[コントロールパネル]-[管理ツール]-[パフォーマンス モニター]のカウンタのどの項目に対応しているかです。

パフォーマンスモニターの解説とネットで調べた限り下記を見ておけばよいかもしれないと思っているのですが、
ご存知の方がいらっしゃったらご教授願いたいです。
・Available MBytes
・Cache Bytes
・Cache Bytes Peak
・Standby Cache Core Bytes
・Standby Cache Normal Priority Bytes
・Standby Cache Reserve Bytes


・下記URLに記載の方法ではなく、上述するような方法で確認したいとのことでした
 http://www.wingfield.gr.jp/blog/2010/02/03/p1680/

パフォーマンス モニター　でメモリリークの調べ方

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食われる原因と対策

# 前提
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サーバーを落ちないように設計することが第一と考え、
その保険として上記のような保険があると良いのかなと思いました。

しかし私は経験に乏しく、
「これって本当に対処法としてありなのか？」
「現実としてやっている開発現場はあるのか？」
といった疑問があり、質問させていただきました。

何卒よろしくお願い致します。

APサーバーが落ちた時の対処方法【再起動はトラブル予防の一環？】

pythonで下記のコードを流したときに、[OSError: [Errno 12] Cannot allocate memory]が発生します。
どのように対策をすればいいか、ご教授願えませんでしょうか。

>subprocess.call(cmd, shell=True)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/subprocess.py", line 557, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1490, in _execute_child
    restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory

＜それに至るまでの処理＞
BigQueryからデータを取得し、結果をcsvファイルに保存します。
その後、GCPに転送するコマンドを発行しようとしたところでエラーが発生します。

df = pd.read_gbq(query, project_name, verbose=False, dialect ='standard')
df_insert.to_csv(csv_file_name, index=False)
cmd = 'bq rm -f '+(BigQueryのテーブル名)
subprocess.call(cmd, shell=True)

＜試したこと＞
del df
gc.collect()
⇒メモリ解放してみたがエラー。各変数の使用メモリを調べ、大きな容量の変数を全て削除し、同様のことを行ったが同じ結果。

subprocess.call('ls')　⇒同じエラー。コマンドの内容には左右されないことが分かる。

この状態で別のターミナルでログインし、pythonを起動した後、
すぐに下記を実行(pandasでデータを取得する処理をパスし。cmdの値は代入した)
subprocess.call(cmd)　⇒正常に実行された。

恐らく、pythonのメモリはgc.collect()で解放されたけど、
subprocessを呼び出すのに必要なC側のメモリが解放されていないのだと思います。
df_insert.to_csvがCで実行されており、その時にメモリ解放が上手くできていないものと予測しています。

この場合に、C側のメモリをpythonから開放するなど、
対応策が浮かぶ方はいらっしゃいますでしょうか。

pythonで Cannot allocate memory エラー

基礎的な質問だと思うのですが気になったため質問します．

#１：vectorのメモリについて

関数内で使用されたvectorのメモリは自動的に開放されるのでしょうか？
```c++
int main(){

std::vector<double> a;

return 0;
}
```
上記のコードのaは何かしらの処理をしたほうが良いのでしょうか？

#2：デストラクタとvectorについて
vectorをclass内で使用した場合，デストラクタでswap関数？を使用してメモリの解放をしろみたいなことを聞きました．なぜ，そのようなことを行わなければならないのでしょうか？