<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE feed [
      <!ENTITY lt "&#38;#60;">
      <!ENTITY gt "&#62;">
      <!ENTITY amp "&#38;#38;">
      <!ENTITY apos "&#39;">
      <!ENTITY quot "&#34;">
      <!ENTITY nbsp "&#160;">
      <!ENTITY copy "&#169;">
]>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title type="text">ブログ</title>
    <subtitle type="text">UJP-Unwired Job Professional</subtitle>
    <updated>2026-07-12T18:22:17+09:00</updated>
    <id>http://www.ujp.jp/modules/d3blog/index.php</id>
    <link rel="alternate" type="text/xhtml" hreflang="ja" href="http://www.ujp.jp/" />
    <link rel="self" type="application/atom+xml" href="http://www.ujp.jp/modules/d3blog/index.php?page=atom" />
    <rights>Copyright (c) 1995-2020</rights>
    <generator uri="http://www.ujp.jp/">D3BLOG - XOOPS BLOG MODULE</generator>
    <entry>
        <title>サービス停止</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=11268" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=11268</id>
        <published>2026-07-07T23:48:00+09:00</published>
        <updated>2026-07-08T12:59:57+09:00</updated>
        <category term="2008 late" label="2008 late" />
        <author>
            <name>ujpblog</name>
        </author>
        <summary type="html" xml:base="http://www.ujp.jp/" xml:lang="ja">　7月6日(月)になった途端に，大量アクセスがありWebサイトが停止状態．　CPU Usageが振り切って，午前0時から18時くらいまで，ほぼデータが取れないくらいの負荷になっている．　大量のSQ...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　7月6日(月)になった途端に，大量アクセスがありWebサイトが停止状態．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15213&ServiceStop1.jpg" align="center" alt="" /></center><br />　CPU Usageが振り切って，午前0時から18時くらいまで，ほぼデータが取れないくらいの負荷になっている．<br /><br />　大量のSQL Injectionなど不正アクセスを疑ったけど，検知システムでも実際のログを見ても検知しておらず．アクセスログをみるとアンソロピックや検索エンジンの各種botからの大量のクローリングが原因でした．<br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15214&ServiceStop2.jpg" align="center" alt="" /></center><br />　Webアクセスをみると，通常とどれだけ違うかわかります．普段はhttpdが12程度で処理できているのに，mpmでのMaxClientsの上限設定の160近くまで跳ね上がっています．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15215&ServiceStop4.jpg" align="center" alt="" /></center><br />　CMSで使っているデータベース側もスレッドが積み上がり，ロックが多くなってしまいました．アクセスが多いとアクセスカウンターの更新処理が入るので，これが負荷になるのですが，攻撃以外でこんなにアクセスされる事はないのです．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15212&ServiceStop3.jpg" align="center" alt="" /></center><br />　対処としてはHTTPDのMacClientsとデータベースのコネクション数を低減させ，大量のアクセスを受け付けずに処理をHTTP 500にさせて稼働を守る方向に．<br /><br />　設定変更後，半日以上かかりましたが，やっと落ち着きました．<br /><br />　なぜ急にアクセスが増えたのかは，今の段階ではわかりませんが，ドント来い設定だったのを最小限設定にできたのは良かったのかな．自宅サーバ運用21年目の夏．<br /><br /><li>データベースの現在の接続数を確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW VARIABLES LIKE &#039;max_connections&#039;;🆑
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.00 sec)

mysql&gt;</code></pre></div><li>設定値を100に変更．<br /><div class="xoopsCode"><pre><code>mysql&gt; SET GLOBAL max_connections = 100;🆑
Query OK, 0 rows affected (0.01 sec)

mysql&gt;</code></pre></div><li>設定値の確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW VARIABLES LIKE &#039;max_connections&#039;;🆑
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 100   |
+-----------------+-------+
1 row in set (0.00 sec)

mysql&gt;</code></pre></div><li>データベースのスレッド数を確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW STATUS LIKE &#039;Threads_connected&#039;;🆑
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 86    |
+-------------------+-------+
1 row in set (0.00 sec)

mysql&gt;</code></pre></div><li>Webサーバを再起動して，再度データベースのスレッドを確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW STATUS LIKE &#039;Threads_connected&#039;;🆑
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 4     |
+-------------------+-------+
1 row in set (0.00 sec)

mysql&gt;</code></pre></div><li>データベースエンジンのステータスを確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW ENGINE INNODB STATUS\G🆑
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
260706  4:50:44 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 16 seconds
----------
BACKGROUND THREAD
----------
srv_master_thread loops: 1 1_second, 1 sleeps, 0 10_second, 2 background, 2 flush
srv_master_thread log flush and writes: 1  log writes only: 5
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 3, signal count 3
Mutex spin waits 0, rounds 0, OS waits 0
RW-shared spins 3, OS waits 3; RW-excl spins 0, OS waits 0
Spin rounds per wait: 0.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter D901
Purge done for trx&#039;s n:o &lt; 0 undo n:o &lt; 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started, OS thread id 2960855040
MySQL thread id 11355, query id 1061000 localhost root
SHOW ENGINE INNODB STATUS
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o&#039;s: 0, sync i/o&#039;s: 0
Pending flushes (fsync) log: 0; buffer pool: 0
42 OS file reads, 7 OS file writes, 7 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 553253, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 44736
Log flushed up to   44736
Last checkpoint at  44736
0 pending log writes, 0 pending chkp writes
10 log i/o&#039;s done, 0.00 log i/o&#039;s/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 136937472; in additional pool allocated 0
Dictionary memory allocated 20888
Buffer pool size   8192
Free buffers       8177
Database pages     15
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 16, created 0, written 1
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
LRU len: 15, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread id 2960240640, state: waiting for server activity
Number of rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

1 row in set (0.00 sec)

mysql&gt;</code></pre></div><li>エラーログの場所を確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW VARIABLES LIKE &#039;log_error&#039;;🆑
+---------------+-----------------------+
| Variable_name | Value                 |
+---------------+-----------------------+
| log_error     | /mysql.err            |
+---------------+-----------------------+
1 row in set (0.01 sec)

mysql&gt;</code></pre></div><li>mysqlcheckを実施．<br /><li>まずはソケットファイルの場所を確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; SHOW VARIABLES LIKE &#039;socket&#039;;
+---------------+---------------------------------------+
| Variable_name | Value                                 |
+---------------+---------------------------------------+
| socket        | /opt/local/var/run/mysql5/mysqld.sock |
+---------------+---------------------------------------+
1 row in set (0.00 sec)

mysql&gt;</code></pre></div><li>データベースをチェック．<br /><div class="xoopsCode"><pre><code>server$ /usr/local/mysql/bin/mysqlcheck -u root -p --auto-repair --all-databases --socket=/opt/local/var/run/mysql5/mysqld.sock🆑
Enter password:🔑
db.db__altsys_language_constants           OK
db.db__avatar                              OK
db.db__avatar_user_link                    OK
db.DB__banner
warning  : 3 clients are using or haven&#039;t closed the table properly
db.db__banner                              OK
db.db__bannerclient                        OK

ー略ー

mysql.columns_priv
error    : Table upgrade required. Please do &quot;REPAIR TABLE `columns_priv`&quot; or dump/reload to fix it!
mysql.db
error    : Table upgrade required. Please do &quot;REPAIR TABLE `db`&quot; or dump/reload to fix it!
mysql.func
error    : Table upgrade required. Please do &quot;REPAIR TABLE `func`&quot; or dump/reload to fix it!
mysql.help_category</code></pre></div><li>高負荷でデータベーストランザクションの不整合が発生して問題が出てる感じ．<br /><div class="xoopsCode"><pre><code>server$ /usr/local/mysql/bin/mysqlcheck -u root -p --auto-repair --all-databases --socket=/opt/local/var/run/mysql5/mysqld.sock🆑
Enter password:🔑
db.db__altsys_language_constants           OK
db.db__avatar                              OK
db.db__avatar_user_link                    OK

ー略ー

mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
mysql.user_info                                    OK
server$</code></pre></div><li>データベースは復旧した．</div>]]>
       </content>
    </entry>
    <entry>
        <title>MacBook Pro 2021 M1 MAX</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=11267" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=11267</id>
        <published>2026-07-06T23:56:58+09:00</published>
        <updated>2026-07-08T02:43:54+09:00</updated>
        <category term="MacBook Pro" label="MacBook Pro" />
        <author>
            <name>ujpblog</name>
        </author>
        <summary type="html" xml:base="http://www.ujp.jp/" xml:lang="ja">　インテルアーキテクチャからARMアーキテクチャに変更されて6年．mac mini 2020 M1も所有しているけど，開発用サブ機なので，やっとメインのパソコンを買おうと検討．　本来はmac mini M4が...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　インテルアーキテクチャからARMアーキテクチャに変更されて6年．mac mini 2020 M1も所有しているけど，開発用サブ機なので，やっとメインのパソコンを買おうと検討．<br />　本来はmac mini M4が欲しいけどローカルLLM構築で人気で納期が数ヶ月先．さらに半導体不足で大幅な値上げをしたので，ちょっと妥協して，それでもメモリとストレージが強化されたモデルを選択して購入．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15211&MacbookProM1MAX1.jpg" align="center" alt="" /></center><br />　64GBで2TB．今使っているのが64GBで1GBのMac Pro 2013なので，どのような性能さがあるか答えてもらった．<br /><br />引用：<div class="xoopsQuote"><blockquote>　Mac Pro 2013のXeon E5 2.7GHz（12コア）とMacBook Pro 2021のM1 Max（10コア）では、M1 Maxがシングルコアで約3.5倍、マルチコアでも約2.5倍高速と、あらゆる面でM1 Maxが圧倒的な性能差を見せつけます。<br />　具体的な性能指標と実作業への影響は以下の通りです。<br /><br />1. CPUベンチマーク比較（Geekbench 6）<br /><br />Mac Pro 2013 (Xeon 12コア)<br />　　シングルコア：約 680<br />　　マルチコア：約 4,900<br /><br />MacBook Pro 2021 (M1 Max 10コア)<br />　　シングルコア：約 2,380<br />　　マルチコア：約 12,300<br /><br />2. グラフィックス（GPU）性能<br /><br />Mac Pro 2013:<br />　デュアルGPU（AMD FirePro D700など）を搭載していますが、基本設計が古く、現在の新しい動画編集・3Dレンダリングの標準であるMetalには最適化されていません。<br /><br />MacBook Pro 2021 (M1 Max):<br />　最大32コアのGPUを内蔵し、さらにProResのハードウェアアクセラレーションにも対応しています。4Kや8Kの動画編集、3D処理においてMac Proとは比較にならないほどの快適さを発揮します<br /></blockquote></div>　3D処理とかはしないのだけど，やっぱりちょっとローカルLLMは動かしてみたい．GPU性能が高いのは良い．<br /><br />　そしてノートパソコンだと気になるバッテリ劣化．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15210&MacbookProM1MAX2.jpg" align="center" alt="" /></center><br /><br /><br />引用：<div class="xoopsQuote"><blockquote>　中古のM1 Max MacBook Proであれば、その状態は十分に良好で平均的な消耗度合いです。不安になる必要はありません。理由は以下の3点です。<br /><br />1. 発売からの期間を考えると標準的<br /><br />　M1 Max搭載のMacBook Proは2021年後半の発売です。約4〜5年が経過していることを考えると、充放電回数200回（年間およそ40〜50回）は「主に電源に繋いで据え置きで使われていた、状態の良い個体」と言えます。<br /><br />2. Appleが定義する寿命の目安Apple公式の基準では、MacBook Proのバッテリーは「充放電回数1,000回で最大容量80%を維持」するように設計されています。<br />　充放電回数 200回：まだ寿命の2割しか消化していません。<br />　バッテリー容量 85%：経年劣化（時間の経過による自然消耗）を考慮すると、200回で85%は極めて自然な数値です。<br /><br />3. 今後の使用への影響<br /><br />　85%あれば、持ち運んでの作業も数時間は十分にこなせます。Appleのバッテリー交換目安である「80%未満」になるまで、まだ1〜2年はそのまま快適に使える可能性が高いです。<br /></blockquote></div>　2年後にバッテリ交換を検討という感じか．そうなるとAppleで交換ができるギリギリだろう．10年使いたいけどな．<br /><br /><br />　今回はヤフオクの横河レンタ・リースで購入しました．ヤフオクの期間限定キャンペーンで1万円引きクーポンも選択できたし，商品は綺麗な感じだし今の所よかったかな．<br /><br /><div class="xoopsCode"><pre><code>商品の合計金額 ： 231,000円
送料：1,540円
クーポン利用分：-10,000円
合計金額：222,540円</code></pre></div></div>]]>
       </content>
    </entry>
    <entry>
        <title>ヤフオクで落札</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=11260" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=11260</id>
        <published>2026-06-29T23:57:47+09:00</published>
        <updated>2026-06-30T12:32:06+09:00</updated>
        <category term="MacBook Pro" label="MacBook Pro" />
        <author>
            <name>ujpblog</name>
        </author>
        <summary type="html" xml:base="http://www.ujp.jp/" xml:lang="ja">　そう言えば，昔も思ったことがあるのだけど，大きなイベントがある日のヤフオクの落札金額が競り上がらない．　その事を思い出したのは，ワールドカップサッカーの2026年5月31日に...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　そう言えば，昔も思ったことがあるのだけど，大きなイベントがある日のヤフオクの落札金額が競り上がらない．<br /><br />　その事を思い出したのは，ワールドカップサッカーの2026年5月31日に開催された対アイスランド代表戦の国際親善試合（交流試合）時間に期限がきた１円入札開始のノートパソコンで，通常3万円から5万円くらいで落札されるものが，なんと３千円で落札されていた．<br /><br />　サッカーの日本戦で狙えば良いと思ったけど，今回，夜中の2時amに試合開始という事で，夕方から寝て備える人が多いようだから，ライバル？が寝ている20時から22時くらいで終了期限を迎えるものを検討して入札．<br /><br />　いちおう，その戦略で主たるライバルも現れず，無駄に値段が釣り上がらずに落札できた．落札価格十分の一ということはなかったけど，10%程度安く変えました．</div>]]>
       </content>
    </entry>
    <entry>
        <title>iPhone 14 plusを買った</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=11222" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=11222</id>
        <published>2026-05-31T23:24:43+09:00</published>
        <updated>2026-06-02T02:09:07+09:00</updated>
        <category term="iPhone" label="iPhone" />
        <author>
            <name>ujpblog</name>
        </author>
        <summary type="html" xml:base="http://www.ujp.jp/" xml:lang="ja">　カミさんが使っているiPhone SE2だけど振り返ると「週末セールでiPhone SE2を買う」として記録しているのが2021年11月なので４年７ヶ月．　バッテリ残量が77%で，容量も128GBで足りなくはな...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　カミさんが使っているiPhone SE2だけど振り返ると「<a href="http://www.ujp.jp/modules/d3blog/details.php?bid=7905" rel="external">週末セールでiPhone SE2を買う</a>」として記録しているのが2021年11月なので４年７ヶ月．　バッテリ残量が77%で，容量も128GBで足りなくはないのだけど，そろそろホームボタンの無いものにもなれなければいけないので，新調した．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15146&iPhone14Plus20260531_2.jpg" align="center" alt="" /></center><br />　買ったのは秋葉原のイオシスで楽天版の新品が92,800円（税込)でした．無駄に？512GBも容量があるけど，未使用品がこのストレージサイズしか無かった．．発売が2022年10月7日で３年８ヶ月前か．．．定価は179,800円なので半額ってことかな．<br />　ちなみになぜiPhone 14 Plusにしたかというと，レッドはこのモデル以降発売されてないからです．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15147&iPhone14Plus20260531_1.jpg" align="center" alt="" /><br>iPhone 13 Proよりでかい</center><br />　これで晴れて？カミさんも１眼レンズを卒業．しかしこのモデルまではLightningケーブルなので，<a href="http://www.ujp.jp/modules/d3blog/details.php?bid=10671" rel="external">去年買ったiPad Air 2025(M3)モデル</a>と共有はできない模様．<br /><br />　最新のモデルはiPhone 17だけど，日本の場合は完全にeSIMで，何か設定を間違えるとキャリアの店舗に行く必要があり，3300円？の支払いが必要になるので，SIMフリー界隈だと人気がないのだとか．</div>]]>
       </content>
    </entry>
    <entry>
        <title>ディスクフルに近くなったので不要ファイルを消そうとしたら35万ファイルもあった．</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=11215" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=11215</id>
        <published>2026-05-26T11:38:13+09:00</published>
        <updated>2026-05-26T11:38:13+09:00</updated>
        <category term="2011 server" label="2011 server" />
        <author>
            <name>ujpblog</name>
        </author>
        <summary type="html" xml:base="http://www.ujp.jp/" xml:lang="ja">　１年前，crucial MX200の500GBが故障して交換したサーバのストレージ，空き容量が少なくなってきた．　MRTGでみると綺麗な右肩上がり．　500GBのストレージだけど100GB程度から400GBほど増え...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　１年前，<a href="http://www.ujp.jp/modules/d3blog/details.php?bid=10740" rel="external">crucial MX200の500GBが故障</a>して交換したサーバのストレージ，空き容量が少なくなってきた．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15126&marsDiskFull20260526_0.jpg" align="center" alt="" /></center><br />　MRTGでみると綺麗な右肩上がり．　500GBのストレージだけど100GB程度から400GBほど増えてる．<br />　このmacは防犯カメラからのメール通知情報をアーカイブ保管しているので，定期的クリーニング(除去)が必要なのでアーカイブファイルを移動させることにしたのだけど，そのアーカイブ，調べてみても60GBしかない．　340GB程度のファイルがどこにあるかわからない．<br /><br />　何がどこにあるのか調べてみることにした．　まずはmacOSが持っているシステムレポート？のストレージ情報から．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15128&marsDiskFull20260526_1.jpg" align="center" alt="" /></center><br />　システムが使っているとなっている．　これだけだと不明なので，管理ボタンを押して確認．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15127&marsDiskFull20260526_2.jpg" align="center" alt="" /></center><br />　やっぱり結局「システム」が使っている事になって詳細は不明．<br /><br />　ちなみにこの不要になったファイルを削除する機能でも，大きいファイル，ダウンロードファイルでも削除できそうなファイルは見つからなかった．<br /><br />　どこになんのファイルがあるかを視覚化してみせてくれるDisk Inventory Xを紹介されたのでインストール．．．不要でダウンロードして起動してみた．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=15129&marsDiskFull20260526_3.jpg" align="center" alt="" /></center><br />　起動してみたかけど調査が終わらない．<br /><br />　仕方ないので，コマンドを使って地道に調べる事に．<br />　rootユーザに成り代わって，普通にルートディレクトリからduで調査してみた．<br /><div class="xoopsCode"><pre><code>mac:/ root# du -sh *🆑
1.3G	Applications
 29G	Library
3.0K	Network
6.4G	System
 37G	Users
458G	Volumes
2.5M	bin
  0B	cores
4.5K	dev
4.0K	etc
1.0K	home
4.0K	installer.failurerequests
1.0K	net
du: private/var/db/ConfigurationProfiles/Store: Operation not permitted
du: private/var/folders/5z/mkkqj8l13yg32k4lrxlh9cgr0000gr/0/com.apple.nsurlsessiond: Operation not permitted
du: private/var/folders/5z/mkkqj8l13yg32k4lrxlh9cgr0000gr/0/com.apple.routined: Operation not permitted
du: private/var/folders/sq/54r_jgb93dd4q95j7bdvb30r0000gn/0/com.apple.nsurlsessiond: Operation not permitted
du: private/var/folders/sq/54r_jgb93dd4q95j7bdvb30r0000gn/0/com.apple.routined: Operation not permitted
du: private/var/folders/sq/54r_jgb93dd4q95j7bdvb30r0000gn/0/SafariFamily: Operation not permitted
du: private/var/folders/sq/54r_jgb93dd4q95j7bdvb30r0000gn/C/com.apple.WebKit.Networking.Sandbox: Operation not permitted
du: private/var/folders/sq/54r_jgb93dd4q95j7bdvb30r0000gn/C/com.apple.WebKit.WebContent.Sandbox: Operation not permitted

du: private/var/folders/zz/zyxvpxvq6csfxvn_n00000y800007k/0/com.apple.nsurlsessiond: Operation not permitted
368G	private🈁
1.1M	sbin
4.0K	tmp
3.9G	usr
4.0K	var
mac:/ root#</code></pre></div>　/privateディレクトリ配下を確認．<br /><div class="xoopsCode"><pre><code>mac:/ root# cd private🆑
mac:private root# ls -la🆑
total 0
drwxr-xr-x   6 root  wheel   204 Jun  3  2025 .
drwxrwxr-t  35 root  admin  1258 May 26 01:54 ..
drwxr-xr-x  96 root  wheel  3264 May 26 01:12 etc
drwxr-xr-x   3 root  wheel   102 Jun  3  2025 tftpboot
drwxrwxrwt  56 root  wheel  1904 May 26 03:14 tmp
drwxr-xr-x  29 root  wheel   986 Jun  3  2025 var
mac:private root#</code></pre></div>　直感でtmpが怪しいと考えて確認．<br /><div class="xoopsCode"><pre><code>mac:var root# sudo du -sh /private/tmp/* | sort -rh | head -n 10🆑
264M	/private/tmp/build_hd_index.3z3pRaKBlSG6E3TX
 60M	/private/tmp/StringTable.Names.dDyFJpc
 48M	/private/tmp/build_hd_index.wBkUjg6lBdkjwJZT
 46M	/private/tmp/build_hd_index.jJUp3R7Of9BaO1cq
 46M	/private/tmp/build_hd_index.UHPZAd0KNhQShiQ1
 35M	/private/tmp/StringTable.Names.njtCUQH
 34M	/private/tmp/StringTable.Names.zvaqjCE
 34M	/private/tmp/StringTable.Names.ezd1AZv
 32M	/private/tmp/build_hd_index.yw3O5IkN9a2wc7T8
 23M	/private/tmp/StringTable.Names.L3WU0kD
mac:var root#</code></pre></div>　大きめのファイルはあるものの，1GB程度だった．<br />　次に/private/var/tmpを確認．<br /><div class="xoopsCode"><pre><code>mac:var root# sudo du -sh /private/var/tmp/* | sort -rh | head -n 10🈁
^C

mac:var root#</code></pre></div>　レスポンスがない．どうもファイル数が多い模様．<br />　そんな時はfindコマンドでファイル数を確認．<br /><div class="xoopsCode"><pre><code>mac:var root# sudo find /private/var/tmp -maxdepth 1 | awk -F/ &#039;{print $NF}&#039; | sed -E &#039;s/[0-9_-]+/X/g&#039; | sort | uniq -c | sort -rn | head -n 20🆑

357256 X.eml
356473 X.zip
  20 iTermX.socket.X
   1 tmp
   1 quicklookdXexitXACXFFXDCXCXAXEAX.tailspin
   1 filesystemui.socket
mac:var root#</code></pre></div>　X.emlというファイルが約36万ファイル．X.zipというファイルもほぼ同じ数存在している．70万ファイル以上あってこれがストレージ空き容量を圧迫し，結果的にmacのレスポンス性能を下げている原因の模様．<br />　tmp以下のファイルなので，OS再起動すれば消えそうな気がする．<br />　ちなみに，uptimeを確認するとこれ．<br /><div class="xoopsCode"><pre><code>mac:var root# uptime🆑
11:14  up 244 days,  7:42, 7 users, load averages: 1.97 2.05 2.08
mac:var root#</code></pre></div>　長い方かな．<br /><br />　サーバを再起動せずにこのファイルを消すとなると，rmコマンドだとArgument list too longがでてエラーになるので，findコマンドを使って消すこととする．<br /><div class="xoopsCode"><pre><code>mac:var root# sudo find /private/var/tmp -maxdepth 1 -name &quot;*.eml&quot; -delete
mac:var root# sudo find /private/var/tmp -maxdepth 1 -name &quot;*.zip&quot; -delete
mac:var root#</code></pre></div>　時間は20分程度かかった．<br />　消えたかどうか確認．<br /><div class="xoopsCode"><pre><code>mac:var root# sudo find /private/var/tmp -maxdepth 2 | cut -d/ -f1-5 | sort | uniq -c | sort -rn | head -n 10🆑
   1 /private/var/tmp/quicklookd_exit_7AC643FF-AAAA-46C2-A516-XXXX0609ZZZZ.tailspin
   1 /private/var/tmp/iTerm2.socket.94829
   1 /private/var/tmp/iTerm2.socket.93570
   1 /private/var/tmp/iTerm2.socket.9070
   1 /private/var/tmp/iTerm2.socket.903
   1 /private/var/tmp/iTerm2.socket.902
   1 /private/var/tmp/iTerm2.socket.900
   1 /private/var/tmp/iTerm2.socket.8505
   1 /private/var/tmp/iTerm2.socket.8495
   1 /private/var/tmp/iTerm2.socket.8492
mac:var root#</code></pre></div>　調べると，これはmacOS High Sierraのバグで，High Sierraから導入されたファイルシステムのAFSとbuild_hd_indexというファイルのインデックス作成を行う機能でこのゴミファイルを作ってしまう模様．　最近のOSでは解消されているそう．<br />引用：<div class="xoopsQuote"><blockquote>　High Sierraの頃は、/private/var/tmp というシステム共通の場所にさまざまなアプリ（Mailなど）が直接一時ファイルを書き込んでいたため、アプリがクラッシュした際に「誰のゴミか分からずシステムも消せない」という状態に陥っていました。現在のmacOSでは、アプリはシステム共通の場所ではなく、アプリごとに完全に隔離された専用のコンテナ領域（~/Library/Containers/ などの内部）に一時ファイルを作るようセキュリティ構造（サンドボックス）が強化されました。万が一アプリがクラッシュしても、そのアプリが次に起動した際や、OSの自動メンテナンスによって、その隔離領域ごと安全かつ確実に掃除される仕組みに変わっています。<br /></blockquote></div>　不要ファイルを消すためのシェル．DeleteTemp.shを準備．<br /><div class="xoopsCode"><pre><code>echo &quot;=== 処理を開始します（root権限） ===&quot;
echo &quot;1. 削除前のファイル数をカウント中...&quot;
before_eml=$(find /private/var/tmp -maxdepth 1 -name &quot;*.eml&quot; -mtime +0 | wc -l)
before_zip=$(find /private/var/tmp -maxdepth 1 -name &quot;*.zip&quot; -mtime +0 | wc -l)

echo &quot;2. 1日前以上の古いファイルを削除中（数分かかる場合があります）...&quot;
find /private/var/tmp -maxdepth 1 \( -name &quot;*.eml&quot; -o -name &quot;*.zip&quot; \) -mtime +0 -delete

echo &quot;3. 削除後のファイル数をカウント中...&quot;
after_eml=$(find /private/var/tmp -maxdepth 1 -name &quot;*.eml&quot; -mtime +0 | wc -l)
after_zip=$(find /private/var/tmp -maxdepth 1 -name &quot;*.zip&quot; -mtime +0 | wc -l)

echo &quot;&quot;
echo &quot;=== 作業結果レポート ===&quot;
echo &quot;【.eml ファイル (1日前以上)】&quot;
echo &quot;  作業前: ${before_eml} 個 -&gt; 作業後: ${after_eml} 個 (削除数: $((before_eml - after_eml)) 個)&quot;
echo &quot;【.zip ファイル (1日前以上)】&quot;
echo &quot;  作業前: ${before_zip} 個 -&gt; 作業後: ${after_zip} 個 (削除数: $((before_zip - after_zip)) 個)&quot;
echo &quot;========================&quot;</code></pre></div>　実行してみた．<br /><div class="xoopsCode"><pre><code>mac:bin root# ./DeleteTemp.sh🆑
=== 処理を開始します（root権限） ===
1. 削除前のファイル数をカウント中...
2. 1日前以上の古いファイルを削除中（数分かかる場合があります）...
3. 削除後のファイル数をカウント中...

=== 作業結果レポート ===
【.eml ファイル (1日前以上)】
  作業前:      528 個 -&gt; 作業後:        0 個 (削除数: 528 個)
【.zip ファイル (1日前以上)】
  作業前:        0 個 -&gt; 作業後:        0 個 (削除数: 0 個)
========================
mac:bin root#</code></pre></div>　これをcrontabに登録しておくとクリーニングしてくれる事に．</div>]]>
       </content>
    </entry>
</feed>