rss ログイン
JJ1RLWのXOOPS Cube Siteにようこそ JJ1RLWのXOOPS Cube Siteにようこそ

サイト内検索

メインメニュー

ログイン


ユーザー名:


パスワード:





パスワード紛失  |新規登録

オンライン状況

4 人のユーザが現在オンラインです。

登録ユーザ: 0
ゲスト: 4

もっと...

アクセスカウンタ

今日 : 188188188
昨日 : 284284284
総計 : 271733271733271733271733271733271733

アクセスカウンター

本日のカウント:285
1日前::437
2日前::548
3日前::567

トータル:835053

人気モジュール

No.1: リンク集(links) 17021
No.2: xpress ブログ 10641
No.3: 資料室 2592
2018/05/31からの合計

ミニカレンダー (piCal)

前月2018年 10月翌月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
<今日>

カレンダー

2018年10月
« 9月    
 123456
78910111213
14151617181920
21222324252627
28293031  

最近の記事内容

    MySQL 8.0のクラッシュ、その後3

    以前にも書いたのですが、MySQL 8.0のクラッシュ、その後、MySQL 8.0.11から8.0.12にアップグレード後、mysql_upgradeコマンドを実行し、正常に終了しました。
    mysqldを再起動してテストしても、やはりクラッシュしてしまいます。

    今回は、システムが使うデータベース(information_schema、mysql、performance_schema、sys)以外のデータベースを一旦削除し、MySQL 5.7から改めてインポートしたら、クラッシュの発生は無くなりました。
    しかし、レスポンスが異常に遅い。

    どの処理が遅いのか、スロークエリーログから改善策を探すことにしました。
    my.iniの内容は、
    slow_query_log=1
    long_query_time=2

    ひとつ目の遅いクエリーは、logcounterxモジュールのlogcounterx_logテーブルを参照している
    SELECT MAX(acccnt), COUNT(recid) FROM hoge_logcounterx_log;
    そこで、
    PRIMARY KEY (recid)

    PRIMARY KEY (recid),
    KEY acccnt (acccnt)

    ふたつ目の遅いクエリーは、analyzer for XCモジュールのanalyzer_dataテーブルを参照している
    SELECT DISTINCT d.mods, COUNT(d.mods) cnt, m.dirname FROM hoge_analyzer_data d,x174_modules m WHERE d.analysis = 1 AND m.dirname IN ( ‘xpress’,’pico’,’d3forum’,’hypconf’,’search’,’ccenter’,’zen-cart-menu’,’sitemap’,’myalbum’,’stdCache’,’NWiki-menu’,’d3downloads’,’d3pipes’,’links’,’xoops-menu’ ) AND d.analysis = 1 AND d.date > 20000101 AND d.mods != ‘index’ AND d.mods = m.name GROUP BY d.mods, m.dirname ORDER BY cnt DESC;
    そこで
    PRIMARY KEY (time,ip,mods),
    KEY date (date),
    KEY ip (ip)

    PRIMARY KEY (time,ip,mods),
    KEY date (date),
    KEY ip (ip),
    KEY mods (mods),
    KEY analysis (analysis)

    以下のクエリーでインデックスを追加出来ます。
    ALTER TABLE プリフィクス_logcounterx_log ADD KEY acccnt (acccnt);
    ALTER TABLE プリフィクス_analyzer_data ADD KEY mods (mods);
    ALTER TABLE プリフィクス_analyzer_data ADD KEY analysis (analysis);
    ※2018/10/15追記

    いずれもインデックスを追加することで、劇的にレスポンスが改善されましたが、まだMySQL 5.7の2~3倍の処理時間が掛かっています。

    しかし、以前のクラッシュの原因については不明です。
    推測ですが、データベースを作成した際に不具合が紛れ込んだのかも知れません。

    試しに再び、MySQL 8.0での運用をしばらく続けようと思います。

    周辺市町村のハザードマップをチェックして見た

    西日本豪雨、台風21号や北海道地震で被災された皆様に心よりお見舞い申し上げます。

    最近、自然災害が多い様に感じ、改めて周辺市町村のハザードマップをチェックして見ました。

    チェックしたのは、香取市、多古町、匝瑳市、旭市などの千葉県北東部です。
    中でも、判り易くまとめられていたのは、匝瑳市のハザードマップです。

    土砂災害、大雨や津波での浸水域を地図上に表示されているので、一目で判る様に上手くまとめられ、より詳細な情報は別に示されいます

    参考サイト
    香取市 – 災害への備え
    多古町 – 災害に備えて
    匝瑳市ハザードマップ
    旭市 – 「旭市防災マップ」を配布します

    Raspberry Pi3(ルーター)初めてのトラブル

    Raspberry pi3(ルーター)初めてのトラブルを経験しました。

    昨日(2018/08/13)16時過ぎ頃に停電(瞬間停電)があった様で、マイロSDカードのルートファイルシステムに矛盾が発生し、起動時にエマージェンシー(メンテナンス)モードになって入力待ち状態で止まって、普通に起動してくれない。

    Give root password for maintenance
    (or type Control-D to continue):
    の様なメッセージで入力待ち状態で止まる。

    ディスプレイ、マウス、キーボードを繋ぎ、入力待ち状態でrootのパスワードを入力してログインし、

    umount /dev/mmcblk0p2
    fsck -y /dev/mmcblk0p2
    reboot

    正常に起動していることを確認してトラブルシューティングは終わりです。

    参考サイト
    RaspbianでWelcome to emergency mode!
    Linuxを強制終了した場合に、起動不良→回復方法

    PHP7対応のまとめ

    以前に投稿したxpress ブログのPHP7対応の記事を資料室にまとめて見ました。

    ※リンクをクリックするとブラウザの新しいウインドウが開きます。
    xpress ブログ記事へのリンク、
    Analyzer for xcの改造
    Analyzer for XC Ver 0.51のPHP7対応
    Analyzer for XC Ver 0.51のPHP7対応その2

    logcounterx Ver 2.74のUTF-8、MySQL、PHP7対応

    myx_backup Ver 1.10のPHP7対応

    PHP7とXOOPS Cube環境下でのPHPエラーメッセージ

    zen-cart Ver1.5.1-jpのPHP7対応での変更点

    資料室の記事へのリンク
    Analyzer for XC Ver 0.51のPHP7対応などまとめ

    logcounterx Ver 2.74のUTF-8、MySQL、PHP7対応などまとめ

    myx_backup Ver 1.10のPHP7対応まとめ

    PHP7とXOOPS Cube環境下でのPHPエラーメッセージ

    zen-cart Ver1.5.1-jpのPHP7対応での変更点

    MySQL 8.0のクラッシュ、その後2

    MySQL 8.0のクラッシュ、その後、MySQL 8.0.11から8.0.12にアップグレード後、mysql_upgradeコマンドを実行し、正常に終了しました。
    mysqldを再起動してテストしても、やはりクラッシュします。

    MyISAMとInnoDBの両方のデータベースエンジンで、クラッシュが発生します。
    作成したばかりのデータベースで、「SHOW TABLE STATUS FROM hogehoge」のクエリーでクラッシュが発生します。
    やはり、以前と同じで、
    [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: row0sel.cc:4603
    とのエラーログが出力されて、mysqldが落ちてしまいます。

    ほかにもクエリーの応答時間が、MySQL 5.7と較べて「激遅」なのも問題です。

    MySQL 8.0のバージョンアップで改善することを期待していましたが、改善していません。

    DDNSの情報が他のDNSに反映されない

    2018/07/13~16にかけて、DDNSの情報が他のDNSに反映されない状況となり、当サイトにアクセス出来ませんでした。

    当サイトが利用しているDDNS(ieServer.netのDDNSサービス)は、結構堅牢なサーバ構成をとっているので、トラブルはめったに無いのですが、一応、DDNSの管理者に連絡し対応して頂きました。

    DDNSを無料で提供してくれている管理者の方に感謝します。

    参考サイト
    無料ダイナミックDNS(DDNS)サービス

    MySQL 8.0のクラッシュ、その後

    MySQL 8.0のクラッシュ、その後、MySQL 8.0インストール初期のmy.ini(my.cnf)を使って、mysqldを起動してテストしても、やはりクラッシュします。

    MyISAMとInnoDBの両方のデータベースエンジンで、クラッシュが発生します。
    作成したばかりのデータベースで、「SHOW TABLE STATUS FROM hogehoge」のコマンドでクラッシュが発生します。
    MyISAMのデータベースを選択した場合でも、
    [ERROR] [MY-012856] [InnoDB] InnoDB: MySQL is trying to perform a consistent read but the read view is not assigned!
    [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: row0sel.cc:4603
    とのログが出力されて、mysqldが落ちてしまいます。

    MySQLのバグリポートに「Bug #90694 Server crashes」という同様の現象が報告されているが、解決策は不明です。

    MySQL 8.0ではシステム関連テーブルがInnoDBになっているので、MySQLのシステムに近いレベルで、エラーが発生している様に思えます。
    MySQL 8.0の次のバージョンで改善することを期待したいと思います。

    ※2018/07/04バグリポートについて追記

サーバ運用情報

現在有効なURLは、通常(http)接続とSSL(https)接続の/xoopscube、/NWiki、/xoopsです。

2017/05/08よりXOOPSをSQL Serverで運用するテストサイトの公開を開始しました。
2014/08/20よりdotnetnukeテスト運用サイトの公開を停止しました。
2014/05/10よりドメイン名を pcboy.dyndns.org から pcboy.dip.jp に変更しました。
2014/04/02よりdotnetnukeテスト運用サイトの公開を開始しました。
2012/02/21より84番ポート接続の/Blogへのアクセスを無効にしました。
2012/02/12より携帯・スマホに対応する機能をONにしました。

2010/09/28より/xoopscubesslのURLを使ったSSL接続を無効にしました。
2009/12/29より古いURLを使ったアクセスを無効にしました。(81番ポートも閉じました)

2009/11/25より24時間運用を実施しています。
深夜の運用停止期間
2009/01/06より22:00-6:00(JST)
2008/08/09より23:00-5:00(JST)

 

Powered by XOOPS Cube 2.2 © 2001-2016 XOOPS Cube Project Distributed by XOOPS Cube 2.2 Distribution Team.