2026.04.20
スタッフブログ
2026年04月20日
グルメ
お客様との食事♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、とんかつのお話です。
先日、新しいパートナー様と一緒に、お客様のところへ訪問しました。
その後、7Gridについて機能紹介しつつ、訪問したお客様の提案方針を検討しました。
打合せも終わり、お昼をご一緒しました。
とっても美味しいとんかつ屋でした♪
美味しかった～♪
今回、そのパートナー様が、ご馳走してくれました。
そのお気持ちが、とても嬉しかったです。
今後も、よろしくお願いいたします。
2026年04月13日
誕生日
誕生日ケーキ♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、ケーキのお話です。
先日、リコーダー仲間から、お誕生日ケーキをいただきました。
HappyBirthday の曲も流れつつ♪
こうやって、みんなからお祝いされるって、幸せだな～と感じつつ、1番にケーキを選ばせてもらいました。笑
気の合う仲間との時間は、大切にしたいと改めて感じました。
2026年04月06日
誕生日
素敵な誕生日プレゼント♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、誕生日プレゼントのお話です。
先日、お客様から、プレゼントをいただきました。
プロジェクトの御礼と、誕生日おめでとう！という事で、なんとリコーダー手入れグッズをいただきました。
こちらがお世話になったのに、プレゼントをいただけた事に感動♪
この手入れクロス、触った感じが抜群で、とっても気に入りました。
Hさん、ありがとうございました！ o(^^)o
2026年03月30日
グルメ
メンチカツ でかっ♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、メンチカツのお話です。
先日、お客様との飲み会がありました♪
無事に7Gridが本稼働したので、お客様と一緒にワイワイやりました♪
そこで登場した1品が、とっても大きなメンチカツ！
唐揚げも、めちゃ大きくて、びっくりでした。
ひょっとして、大味なのかな？と思いつつ食べましたが、どちらも美味しかったです♪
かなり賑やかな飲み会でした。
お客様とこういう会が開催できるって、幸せですね。
これからもお仕事、頑張ります♪
2026年03月23日
SQLserver
SQL Server のログに「パフォーマンスが低下する可能性があります」と出た話
こんにちは。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 全体のメモリ逼迫が見える
といった状況になったら、その時は改めて深掘りすれば良いかなと考えています。
皆様のお役に立てれば幸いです。
2026年03月16日
グルメ
レタス大好きです♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、レタス大好き♪のお話です。
先日、ロピアに行ったら、レタスが1玉140円でした。
安いな～と思って、1玉購入。
そして、その日の夜は、レタスてんこ盛りのスパゲティーを作りました♪
ペペロンチーノ風にしつつ、ベーコンとレタスを具にして
少し汁がお皿に残るくらいにして作りました。
美味しかった～♪（自画自賛♪）
少し火を入れた、ちょっとクタっとしたレタスって、好きなんですよね。
ベーコンとの相性もばっちり♪
（写真は大盛なので、盛付が雑ですが、お許し下さい。）
次は何を作ろうかな～♪
2026年03月09日
グルメ
ラーメン 三太♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、ラーメンを食べに行ったお話です。
先日、浜松駅近くのモール街にある「ラーメン三太」に行ってきました♪
ここのお店は、会社メンバーが大好きなお店です。
https://www.trest-hamamatsu.com/santa/
私はねぎ醤油に、キムチをトッピングしました。
美味しかった～♪
ラーメン、好きなんですよね～。笑。
とんこつラーメンなのですが、臭みがなく、個人的には大好きな味です。
少し遅い時間に行ったのですが、お客さんがいっぱいでした。
また行こうっと♪
2026年03月02日
音楽
バロック式とジャーマン式♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は、リコーダー♬のお話です。
タイトルを見て、すぐにソプラノリコーダーの事だと理解した方は、リコーダーが好きな方だと思います。
今まで私は、ジャーマン式のソプラノリコーダーを吹いていましたが、今回、バロック式の方を購入しちゃいましたっ♪
並べてみるとよくわかるのですが、穴の大きさが違うんですね。
木目調の方が、今まで吹いていたジャーマン式。
エポニー調の方が、今回購入したバロック式。
なぜ今回バロック式を購入したのか、というと、
①リコーダーを永く楽しむならバロックの方が指使いが良いと教えてもらった。
②ソプラノだけでなく、アルトリコーダーも吹くようになった。アルトはバロック式。
という理由です。
今回購入したリコーダーって、3000円程度。
それでいて、しっかり楽器なので、コスパ最強の楽器だと思っています。
2026年02月24日
SQLserver
【SQL Server】TEMPDB のデータファイルが巨大で困ったけど…調べたら “むしろ適正”？
こんにちは。NANAシステム開発SYです。今回は技術ネタです。
■最適サイズを探っていくための記録
SQL Server を運用していると、tempdb のサイズが気づいたらとんでもなく大きくなっていた――という経験は多くの管理者が一度は通る道ではないでしょうか。
先日、まさに自分の環境で同じ状況に遭遇し、「これはさすがに大きすぎるのでは？」と思って調査を始めました。
ところが色々調べていくうちに、
「あれ？これ Microsoft の推奨サイズ（＝適正サイズ）に近いのでは…？」
という結論に近づいていきました。
今回はその気づきと、実際に tempdb がどれだけ使われているかを記録し、最適サイズを導き出すまでのプロセスをまとめます。
■ そもそも tempdb は “大きくなるもの”
tempdb は SQL Server の作業領域として、次のような処理に使われるようです。
・ORDER BY / GROUP BY など大規模ソート
・ハッシュ結合・ハッシュ集計
・一時テーブル・テーブル変数
・Snapshot Isolation / RCSI のバージョンストア
・インデックス再構築（ONLINE）
このため、上記をガンガン行うアプリケーションほど tempdb はよく伸びます。
しかも、SQL Server はサービス再起動のたびに tempdb を初期サイズにリセットするため、
初期サイズが小さいとピーク負荷時に一気に巨大化してしまうことがあります。
なので、「ファイルを小さくしても、また必要に応じて大きくなった」と感じることがあります。
縮小コマンドもあるのですが、縮小しても、負荷が来れば SQL Server が自動で再拡張します。逆に言えば、縮小を繰り返すと
「縮小 → 拡張 → 縮小 → 拡張」
という悪循環が起き、パフォーマンスを落としていたように思います。
「縮小 → 拡張 → 縮小 → 拡張」
という悪循環が起き、パフォーマンスを落としていたように思います。
■ Microsoft の推奨サイズに “落ち着いていた” という気づき
tempdb の適正サイズは
「CPU コア数 ×（8GB 〜 16GB / ファイル）」
というのが Microsoft の基本推奨です。
例えば CPU 8コアなら：
・ファイル数：8個
・1ファイル初期サイズ：8GB
・合計：64GB
巨大化したと悩んでいた環境でふと確認すると、まさに この推奨レンジに収まっていた のです。
「巨大化した！」と焦ったわりには、ただの最適化された姿だったわけです。
■ とはいえ、“実際にどれだけ使っているか” を知らないままでは判断できない
でも、いくら推奨値に収まっているとはいえ、本当に適正かどうかはワークロードを見て決めるべきです。
そこで、tempdb の使用量を 時系列でログに残す仕組み を作りました。
▼ TEMPDB の“実際の使用量”をログに残す T‑SQL
以下のようにログテーブルを作り、
SQL Server Agent で 1分ごとに実行することで
ピーク時の tempdb 消費量を詳細に把握できます。
▼ ログテーブル作成
CREATE TABLE dbo.TempdbUsageLog
(
LogId bigint IDENTITY(1,1) PRIMARY KEY,
LogTime datetime2(3) NOT NULL DEFAULT (SYSUTCDATETIME()),
TotalFileSizeMB decimal(18,2),
UsedMB decimal(18,2),
UserObjMB decimal(18,2),
InternalObjMB decimal(18,2),
VersionStoreMB decimal(18,2),
UnallocatedMB decimal(18,2),
DataFiles int
);
▼ 採取用プロシージャ
CREATE PROCEDURE dbo.Capture_Tempdb_Usage
AS
BEGIN
SET NOCOUNT ON;
;WITH Files AS
(
SELECT
name,
FileSizeMB = (size * 8.0) / 1024.0,
UsedMB = (FILEPROPERTY(name,‘SpaceUsed’) * 8.0) / 1024.0
FROM tempdb.sys.database_files
WHERE type = 0
),
SpaceUsage AS
(
SELECT
UserObjMB = SUM(user_object_reserved_page_count) * 8.0 / 1024.0,
InternalObjMB = SUM(internal_object_reserved_page_count) * 8.0 / 1024.0,
VersionStoreMB = SUM(version_store_reserved_page_count) * 8.0 / 1024.0,
UnallocatedMB = SUM(unallocated_extent_page_count) * 8.0 / 1024.0
FROM sys.dm_db_file_space_usage
)
INSERT dbo.TempdbUsageLog (TotalFileSizeMB, UsedMB, UserObjMB, InternalObjMB, VersionStoreMB, UnallocatedMB, DataFiles)
SELECT
(SELECT SUM(FileSizeMB) FROM Files),
(SELECT SUM(UsedMB) FROM Files),
su.UserObjMB,
su.InternalObjMB,
su.VersionStoreMB,
su.UnallocatedMB,
(SELECT COUNT(*) FROM Files)
FROM SpaceUsage su;
END
■ ログを取り始めてわかったこと
最初の数日記録をとってみて分かったのは、
・殆ど使っていない時間帯が多い
・逆に特定時間帯だけドカンと増える
ということ。
■ 今後の方針：実測しながら最適値に寄せていく
今後はログデータをもとに、
・ピーク使用量 + 20〜30% の余裕
・拡張が発生しない初期サイズ
・適切な autogrowth 設定（%ではなく固定MB）
これらを調整し、tempdb を“業務に最適化されたサイズ”へ整えていく予定です。
■ まとめ
・TEMPDB は負荷によって大きくなるのが普通
・縮小してもまた必要に応じて拡張する
・Microsoft 推奨サイズに近いことも多い
・本当に妥当かどうかは、実際の使用量をログに残して判断するべき
・ログを取るとワークロードの癖が見えてくる
・そこから初めて “最適サイズ” の議論ができる
tempdb の巨大化は “壊れている” のではなく、「あなたのワークロードを反映した姿」 であることが多いです。なので大事なのは、まずは実測から始めることだと感じました。
これが tempdb 最適化のスタート地点だと実感した出来事でした。些細な情報ですが、皆様のお役に立てれば幸いです。
2026年02月16日
UFOキャッチャー
うさぎ（ちいかわ）スタンドライト♪
皆様、こんにちは♪ NANAシステム開発HYです。
今回は（も？）ちいかわグッズのお話です。
先日、KSさんから、
またまたUFOキャッチャーちいかわグッズが届きました♪
なんと、うさぎのUSBスタンドライトです！
目が光るとの事♪
さっそくパソコンへ繋いで… と思ったのですが、
弊社では許可されたもの以外のUSB接続は禁止。(^^;
という事で、とりあえず組立だけしました。笑。
KSさん、ありがとうございますっ！
