<?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-08-21T12:12:59+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>セッションテーブルのエラーでログインができなくなる</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=10674" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=10674</id>
        <published>2025-04-24T23:59:36+09:00</published>
        <updated>2025-04-30T01:56:30+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">　サイトは動いているけど，ログインができなくなった．こんなメッセージが表示される．　これｈXOOPSCubeのセキュリティプラグインProtectorに関するもの．　昨晩大量のSQLインジェクショ...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　サイトは動いているけど，ログインができなくなった．こんなメッセージが表示される．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=14026&MySQLTicketError.jpg" align="center" alt="" /></center><br />　これｈXOOPSCubeのセキュリティプラグインProtectorに関するもの．<br /><br />　昨晩大量のSQLインジェクションなどを受けたのでクロスサイトスクリプティングも受けていただろう．．．DDoSには少し弱いかもしれない．<br /><br />　セッションデーブルを確認．<br /><br /><div class="xoopsCode"><pre><code>mysql&gt; select count from XOOPSDB__session;🆑
ERROR 145 (HY000): Table &#039;./XOOPSDB/XOOPSDB__session&#039; is marked as crashed and should be repaired
mysql&gt;</code></pre></div>　やはりユーザセッションを管理するテーブルが壊れていた模様．<br />　修復する．<br /><br /><div class="xoopsCode"><pre><code>mysql&gt; REPAIR TABLE XOOPSDB__session;🆑
+------------------------+--------+----------+----------+
| Table                  | Op     | Msg_type | Msg_text |
+------------------------+--------+----------+----------+
| xoops.xoopsdb__session | repair | status   | OK       |
+------------------------+--------+----------+----------+
1 row in set (0.09 sec)

mysql&gt;</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=10552" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=10552</id>
        <published>2025-02-12T19:11:31+09:00</published>
        <updated>2025-02-13T01:54:34+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">　2009年10に２台買った整備調整品のMacBook late 2008ですが，その時DVDドライブに初期不良のあったのが２号機．その後，カミさんのメインPCとしたけど使われず，寝ていた期間が長かったけ...</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=666" rel="external">2009年10に２台買った整備調整品のMacBook late 2008</a>ですが，その時DVDドライブに初期不良のあったのが２号機．その後，カミさんのメインPCとしたけど使われず，寝ていた期間が長かったけど，気がついたら起動しなくなってました．<br />　そして代替え機として2024年9月にヤフオクで予備機の代替機を購入．<br /><br /><div class="xoopsCode"><pre><code>落札金額：4,400円
送料：910円
支払金額：5,310円</code></pre></div><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=13821&MacBookLate2008_No3.jpg" align="center" alt="" /></center><br />　商品説明にはこう買いてあった．<br /><br />引用：<div class="xoopsQuote"><blockquote>商品は譲渡頂いたお品で本体、電源コード、キーボード保護カバー他画像にある物だけになり、本体は小さなスリキズ等は確認できるものの、表面、裏面、タッチパッドには保護フィルムが付いたままで、私感ですが極上の美品中古の部類ではないかと思います。<br />しかしながら、バッテリーが経年劣化で使えない、本体に認識されていない商品になります。（画像9参照）<br />電源コードは汚れや何かしらの色の付着がございます。<br /><br />通電と一部動作確認済（ネット通信、CD・DVDの再生読み込み）。画像7、8参照<br />ネット通信はOSやブラウザが古いので展開はできませんでした。<br />タッチパッドには保護フィルムが付いたままですので動作確認時の反応は悪く、剥がしておりませんので本来の状態は確認できていない現状となります。<br /></blockquote></div><br />　元箱も完備で本体は綺麗．しかしタッチパッドがクリックできない．この機種，裏返してバッテリを外すとタッチパッドのクリックをネジで調整する機能があるけど，それをしても調整できない．どうも持病として不具合があった模様．<br /><br />　早速２号機からメモリとSSDを移植して起動してよくみたら，MacBook 2008 lateの中の上位CPU版のIntel Core 2 Duo 2.4GHz版でした．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=13822&MacBookLate2008_No3_2.jpg" align="center" alt="" /></center><br />　意図せず20%の性能アップ．<br /><br />　そこまで準備して放置していたのだけど，最近，１号機が不定期にダウンする．稼働中も冷却ファンからの異音が．．．<br /><br />　<a href="http://www.ujp.jp/modules/d3blog/details.php?bid=672" rel="external">初期不良の修理から戻ってきたのが2009年10月17日</a>なので，そこから計算したらこんな感じでした．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=13823&MacBookLate2008_No3_3.jpg" align="center" alt="" /></center><br />　ほぼ15年4ヶ月．ハードもソフトも，色々とカスタマイズしたので新しいサーバへの移行はとても難しい．．．<br /><br />　そして新たな予備機の準備が必要．．．<br /><br /><u><b>追記2025/02/13</b></u><br />　１号機から３号機に交換して，CPUスペックが上昇したけど，それによりCPU温度が下がった事が確認できた．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=13827&MacBookLate2008_No3_4.jpg" align="center" alt="" /></center><br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=13826&MacBookLate2008_No3_5.jpg" align="center" alt="" /></center><br />　CPU温度が下がっているけど，その他のパームレストやバッテリ温度は変化がない感じ．CPU性能がアップしたことで改善した事が確認できた．</div>]]>
       </content>
    </entry>
    <entry>
        <title>（１号機）　mysqldump: Got error: 145: Table &#039;./WEBDB/WEBDB__session&#039; is marked as crashed and should be repaired when using LOCK TABLES</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=10534" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=10534</id>
        <published>2025-02-04T13:37:32+09:00</published>
        <updated>2025-02-12T18:35:27+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">　crontabで定期実行しているMySQLのバックアップが失敗している．失敗というかダンプファイルが肥大化しでディスクフルになった．．．　手動で実行してみたら，こんなエラーだった．sh-...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　crontabで定期実行しているMySQLのバックアップが失敗している．失敗というかダンプファイルが肥大化しでディスクフルになった．．．<br />　手動で実行してみたら，こんなエラーだった．<br /><br /><div class="xoopsCode"><pre><code>sh-3.2# DBbackup.sh
mysqldump: Got error: 145: Table &#039;./WEBDB/WEBDB__session&#039; is marked as crashed and should be repaired when using LOCK TABLES
sh-3.2#</code></pre></div><br />　これはWebアクセスのセッションテーブルが壊れている模様．DDoS攻撃を受けた結果，被害が出たと推察．<br /><br />　まずは壊れたテーブルを確認．<br /><div class="xoopsCode"><pre><code>mysql&gt; check table WEBDB__session;🆑
+------------------------+-------+----------+-------------------------------------------------------------------------------------------+
| Table                  | Op    | Msg_type | Msg_text                                                                                  |
+------------------------+-------+----------+-------------------------------------------------------------------------------------------+
| WEBDB.WEBDB__session | check | warning  | Table is marked as crashed                                                                |
| WEBDB.WEBDB__session | check | warning  | 13 clients are using or haven&#039;t closed the table properly                                 |
| WEBDB.WEBDB__session | check | warning  | Size of indexfile is: 913408      Should be: 659456                                       |
| WEBDB.WEBDB__session | check | error    | Invalid key block position: 270216091030151533  key block size: 1024  file_length: 659456 |
| WEBDB.WEBDB__session | check | error    | key delete-link-chain corrupted                                                           |
| WEBDB.WEBDB__session | check | error    | Corrupt                                                                                   |
+------------------------+-------+----------+-------------------------------------------------------------------------------------------+
6 rows in set (2.97 sec)

mysql&gt;</code></pre></div> haven't closed the table properly（適切に閉じてない）．delete-link-chainが壊れているとのこと．<br /><br />　delete-link-chainはMyISAMで，削除されたレコードを管理する仕組みで，これが壊れているということになる．<br /><br />　リペアを実行して再度チェックして修復できたことを確認．<br /><br /><div class="xoopsCode"><pre><code>mysql&gt; repair table WEBDB__session;🆑
+------------------------+--------+----------+------------------------------------------+
| Table                  | Op     | Msg_type | Msg_text                                 |
+------------------------+--------+----------+------------------------------------------+
| WEBDB.WEBDB__session | repair | warning  | Number of rows changed from 1800 to 1797 |
| WEBDB.WEBDB__session | repair | status   | OK                                       |
+------------------------+--------+----------+------------------------------------------+
2 rows in set (0.29 sec)

mysql&gt;

mysql&gt; check table WEBDB__session;🆑
+------------------------+-------+----------+----------+
| Table                  | Op    | Msg_type | Msg_text |
+------------------------+-------+----------+----------+
| WEBDB.WEBDB__session | check | status   | OK       |
+------------------------+-------+----------+----------+
1 row in set (0.01 sec)

mysql&gt;</code></pre></div></div>]]>
       </content>
    </entry>
    <entry>
        <title>（１号機）　Apacheの定期再起動はパフォーマンス改善に効果がある</title>
        <link rel="alternate" type="text/xhtml" href="http://www.ujp.jp/modules/d3blog/details.php?bid=9679" />
        <id>http://www.ujp.jp/modules/d3blog/details.php?bid=9679</id>
        <published>2023-11-18T09:28:21+09:00</published>
        <updated>2025-02-12T18:35:11+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">　某サーバのuptimeを確認．juno:$ uptime🆑
 2:59  up 665 days,  9:28, 2 users, load averages: 0.18 0.30 0.31
juno:$　以前542日と言うのがあったけど，それを更新していた模様．　665日前と言うと，2022年1月2...</summary>
       <content type="html" xml:lang="ja" xml:base="http://www.ujp.jp/">
<![CDATA[<div>　某サーバのuptimeを確認．<br /><br /><div class="xoopsCode"><pre><code>juno:$ uptime🆑
 2:59  up 665 days,  9:28, 2 users, load averages: 0.18 0.30 0.31
juno:$</code></pre></div>　以前<a href="http://www.ujp.jp/modules/d3blog/details.php?bid=3729" rel="external">542日</a>と言うのがあったけど，それを更新していた模様．<br />　665日前と言うと，2022年1月22日か．<a href="http://www.ujp.jp/modules/d3blog/details.php?bid=8091" rel="external">体温計を買ったりしていた</a>ようで，どうして再起動したのかは覚えてないなぁ．．．<br /><br />　ふと気づいたのだけど．<br />　先週，ログ出力タイミングを変更するために，Apache httpdを再起動(apachectrl stop;apachectrl start)したんだけど，そうするとCPU timeが減りました．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=11960&httpd20231118_1.jpg" align="center" alt="" /></center><br />　そして，もっと長い目で見ると長期間動作したまま運用していると，httpdのCPUタイムがどんどん増えていることが確認できました．<br /><br /><center><img src="http://www.ujp.jp/modules/xelfinder/index.php?page=view&file=11959&httpd20231118_2.jpg" align="center" alt="" /></center><br />　これは興味深い．<br /><br />　ちなみに，Apache 1.3脳なのでMPMはpreforkで設定してあります．<br /><br /><div class="xoopsCode"><pre><code>juno$ /opt/local/apache2/bin/apachectl -V|grep MPM🆑
Server MPM:     Prefork
 -D APACHE_MPM_DIR=&quot;server/mpm/prefork&quot;
juno$</code></pre></div>　MPMの詳細はこれ．<br /><br /><div class="xoopsCode"><pre><code>juno$ cat /opt/local/apache2/conf/extra/httpd-mpm.conf🆑
# worker MPM
&lt;IfModule mpm_worker_module&gt;
    StartServers          2
    MaxClients          200
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   5000
&lt;/IfModule&gt;</code></pre></div>　つまり5000リクエスト処理したらプロセスが死滅するようにしているので，メモリリークとかがあってもサーバOSダウンにならないよう制御しているのですが，親プロセスか何かが長期間運用しているとゴミ？が溜まって動作が重くなって非効率化し，CPUタイムをたくさん消費する状態になっていると言うことのよう．<br />　それを解消するには，OSの再起動までいかなくても，Apache httpdを再起動で効果が出る模様．<br /><br />　実際，その某サーバのWebページにアクセスすると，レスポンスがとても速い．やっぱり定期再起動を入れておくのが良いのかな．<br /><br />　そして今回は，DirectoryServiceの再起動を兼ねてOS再起動を実施したのでまた色々とリセットされたのだけど，Apache httpdだけ定期再起動にしてみよう．</div>]]>
       </content>
    </entry>
</feed>