スタッフブログ

皆様、こんにちは♪　NANAシステム開発HYです。
今回は、メンチカツのお話です。

 

先日、お客様との飲み会がありました♪
無事に7Gridが本稼働したので、お客様と一緒にワイワイやりました♪

 

そこで登場した1品が、とっても大きなメンチカツ！
唐揚げも、めちゃ大きくて、びっくりでした。
ひょっとして、大味なのかな？と思いつつ食べましたが、どちらも美味しかったです♪

 

かなり賑やかな飲み会でした。
お客様とこういう会が開催できるって、幸せですね。

 

これからもお仕事、頑張ります♪

 

 

 

こんにちは。NANAシステム開発SYです。今回は技術ネタです。

ある日、DB サーバのイベントログを眺めていたところ、

「SQL Server のメモリがページアウトされ、パフォーマンスが低下する可能性があります」

という、なかなか不穏な警告が出ているのに気づきました。該当するログはこれです。

---

イベント ID 17890（ソース：MSSQLSERVER）

SQL Server プロセス メモリの重要な部分がページ アウトされました。

これにより、パフォーマンスが低下する可能性があります。

---

文面だけ読むと、

• メモリが枯渇している？
• 実はもう遅くなっている？
• 何か設定を変えないとまずい？

と、つい身構えてしまいがちですが、、、

こういうログこそ一旦落ち着いて事実を整理するのが大事だと思います。

 

イベント ID 17890 とは何か

 

まず、このイベント ID 17890 ですが、SQL Server が「自分のプロセスに割り当てられているメモリのうち、物理メモリとして保持されている割合がかなり低い状態だな」と判断したときに出す警告ログです。ポイントは、Warning（警告）であってエラーではない今すぐ障害、という意味ではないというところ。
要は、「この状態が続くと、パフォーマンスに影響する可能性があるよ」という、いわば事前注意的なログってことです。

 

ログに出てくる各数値の意味

 

このイベントには、だいたい以下の数値がセットで出力されます。今回のログでは、こうなっていました。

Duration（秒）：603
Working set (KB)：339,944（約 340MB）
Committed (KB)：783,632（約 780MB）
Memory utilization (%)：43

これだけだと、何事か分からないので、それぞれ順に説明していきますね。

---

■ Duration（秒数）

 

ページアウト状態がどれくらいの時間続いているか を示します。

0 秒 → 検出直後
数百秒 → 「しばらくこの状態」

今回は 603 秒なので、一瞬ではなく、ある程度継続していたことが分かります。

 

■ Working set（作業セット）

 

SQL Server プロセスが、実際に物理メモリ（RAM）上に置いてもらえている量です。OS が「ちょっとメモリ空けたいな」と判断すると、ここが削られ、ページアウトされていきます。

 

■ Committed（コミット済みメモリ）

 

SQL Server が「自分はこれだけメモリを確保している」と認識している総量です。これは、実メモリとページファイル（仮想メモリ）を合わせた概念になります。

 

■ Memory utilization（%）

 

「確保しているメモリのうち、何％が物理メモリに載っているか」を見るための指標です。次の計算結果が表示されています。

Working set ÷ Committed × 100

---

 

では、上記の理解を元に今回の数値が示していることを整理していきます。

 

確保しているメモリ：約 780MB

実際に物理上にあるメモリ：約 340MB

つまり、物理メモリ上にあるのは約 43% という状態です。

 

SQL Server は、この状態を見て、「確保してるメモリの半分以上がページアウトされちゃってるな」と判断し、イベント ID 17890 を出した、という流れになります。

一般的にこの警告は、Working set ÷ Committed の比率が 50% を大きく下回る状態が一定時間続いた場合に出やすいと言われています。

※ なお、これはMicrosoftの公式サイトによると、公開された厳密な仕様値というより、SQL Server 内部の判断ロジックによるものです。実務的には「50% が一つの目安」と考えて問題ないと思います。

 

今回は問題になるのか？

 

ここが一番気になるところですが、結論から言うと 今回は特に問題になるケースではなさそうです。というのも、以下の要因が判っていたからです。

・ログが出ている時間帯で、大きなクエリやバッチが動いていない

・SQL Server は低負荷時に大量の物理メモリを保持し続ける必要がない

・OS 側の都合で一時的にページアウトされるのは普通に起きる

 

そもそもなんですが、SQL Server は、

１．まず物理メモリを使う

２．足りなければページングに回る

という性質を持っています。そのため、今後負荷が上がれば、

 

１．物理メモリが再び割り当てられる

２．Working set が増える

３．Memory utilization が回復して、この警告も自然に出なくなる

 

という動きになる可能性が高いと考えます。

 

設定変更で消すべきか？

 

ちなみに、「この警告が出るのが嫌だから何か設定を変えたい」という話であれば、
min server memory を 0 ではなく、ある程度大きな値（例えば 10GB など）にする、という選択肢はあります。

ただしこれは、実際に性能問題が起きているわけではないのに、単にログを見えなくするだけの目的で行うため、OS 側のメモリ余裕を減らすリスクもあります。

そういった点を考えると、あまり意味のある対処とは言えないかな、という印象です。

 

結論

 

まとめると、

・イベント ID 17890 は即障害を示すものではないことが判った。

・今回の数値で警告が出た理由は、仕組み的に妥当だった。

・低負荷時に一時的に出る分には特に問題ないと考えてもいいと思う。

・実際の性能劣化がなければ、基本は放置で OKと思う。

という事なので、

今回は「仕組みとして理解しておけば十分な警告」

という結論に落ち着きました。

 

今後もし、

・高負荷時にも頻繁に出る

・体感できる遅延とセットで起きる

・OS 全体のメモリ逼迫が見える

といった状況になったら、その時は改めて深掘りすれば良いかなと考えています。

皆様のお役に立てれば幸いです。

皆様、こんにちは♪　NANAシステム開発HYです。
今回は、レタス大好き♪のお話です。

 

先日、ロピアに行ったら、レタスが1玉140円でした。
安いな～と思って、1玉購入。

 

そして、その日の夜は、レタスてんこ盛りのスパゲティーを作りました♪
ペペロンチーノ風にしつつ、ベーコンとレタスを具にして
少し汁がお皿に残るくらいにして作りました。

 

美味しかった～♪（自画自賛♪）
少し火を入れた、ちょっとクタっとしたレタスって、好きなんですよね。
ベーコンとの相性もばっちり♪
（写真は大盛なので、盛付が雑ですが、お許し下さい。）

 

次は何を作ろうかな～♪

 

 

 

 

皆様、こんにちは♪　NANAシステム開発HYです。
今回は、ラーメンを食べに行ったお話です。

 

先日、浜松駅近くのモール街にある「ラーメン三太」に行ってきました♪
ここのお店は、会社メンバーが大好きなお店です。
https://www.trest-hamamatsu.com/santa/

 

私はねぎ醤油に、キムチをトッピングしました。
美味しかった～♪
ラーメン、好きなんですよね～。笑。
とんこつラーメンなのですが、臭みがなく、個人的には大好きな味です。
少し遅い時間に行ったのですが、お客さんがいっぱいでした。

 

また行こうっと♪

 

皆様、こんにちは♪　NANAシステム開発HYです。
今回は、リコーダー♬のお話です。

 

タイトルを見て、すぐにソプラノリコーダーの事だと理解した方は、リコーダーが好きな方だと思います。

 

今まで私は、ジャーマン式のソプラノリコーダーを吹いていましたが、今回、バロック式の方を購入しちゃいましたっ♪
並べてみるとよくわかるのですが、穴の大きさが違うんですね。
木目調の方が、今まで吹いていたジャーマン式。
エポニー調の方が、今回購入したバロック式。

 

なぜ今回バロック式を購入したのか、というと、
①リコーダーを永く楽しむならバロックの方が指使いが良いと教えてもらった。
②ソプラノだけでなく、アルトリコーダーも吹くようになった。アルトはバロック式。
という理由です。

 

今回購入したリコーダーって、3000円程度。
それでいて、しっかり楽器なので、コスパ最強の楽器だと思っています。