n日問題(497日問題とその亜種とか)

※2023/11/05 タイトルを「n日問題」から「n日問題(497日問題とその亜種とか)」に変更した。

コンピュータを用いたシステムにおいてはn日問題っていうのがある。稼働後n日経過によって、何らかの不具合が発生するという問題だ。

n日問題っていうのは、ほぼオーバーフローで発生する。大体稼働開始からのカウンタが2の32乗を超えたところで発生する。2の32乗は大体プラスマイナス21億くらいだから、カウンタが1/100秒なら2千万秒(248日)、カウンタが1/1000秒なら2百万秒(24.8日)で問題が起こる。マイナスを使用しない(アンサインな)数値であれば、43億なのでカウンタが1/100秒なら4.3千万秒(497日)、カウンタが1/1000秒なら4.3百万秒(49.7日)で問題が起こる。同様にカウンタが1/60秒なら7.16千万秒(828日)で、1/50秒なら8.6千万秒(994日)で、1/40秒なら1.07億秒(1243日)で発生する。

変わり種としては、クロックが32MhzのPCIをカウントしたら、6byteのサイン付きカウンタを埋め尽くして51日でオーバーフロー発生するなんてこともあったようだ*1

なぜこんな問題が良く発生するのかといえば、n日連続稼働させないと問題が発生しないからだ。非常にテストがし辛い。たとえばテスト項目として「497日立ち上げっぱなしにしておく」というのはあり得ない。どうしてもテストしたければ「n-1日稼働した状態にカウンタを変更しておいて、そこからしばらく動作させて確認する」ということになる。

ということで、過去存在するn日問題を以下に例示する。発生させたメーカーの顔ぶれをみれば、如何にこの問題の予期が難しいのかが良く分かる。

  • 24.8日問題
FlashPlayerで発生する問題
https://helpx.adobe.com/jp/flash-player/kb/cpsid_93924.html ↑WebArchive
https://web.archive.org/web/20201004153519/https://helpx.adobe.com/jp/flash-player/kb/cpsid_93924.html
  • 49.7日問題
CanonのDAサーバで発生する問題
http://www.canon-its.co.jp/wonder/topics/20060606daserver.html ↑の痕跡
https://www.canon-its.co.jp/files/user/products/intouch_family/download/detail/was30sp2_readme_japanese.html
古いWindows(2000以前)で発生した問題
http://blog.livedoor.jp/blackwingcat/archives/1824244.html
Apresiaで発生した問題
http://www.apresia.jp/products/apresialight/support/information/information3.html
Windows8.1/2012R2で発生する問題
https://support.microsoft.com/ja-jp/help/3185911/ms16-106-description-of-the-security-update-for-microsoft-graphics-component-september-13,-2016
windowsに標準搭載されたintelサウンドドライバで発生する問題
https://www.hitachi-ip.co.jp/products/hfw/pdf/201904_USBSound.pdf
  • 51日問題*2
ボーイングの旅客機で使用されているVxworksで発生した問題(原因は推測っぽいけれども)
https://ioactive.com/reverse-engineers-perspective-on-the-boeing-787-51-days-airworthiness-directive/
  • 208.5日問題
RHELXeonの組み合わせで発生した問題
http://hisayosh.github.io/posts/2013/12/208days-problem/
  • 248日問題
Oracle DB 10.2で発生した問題
http://www.drk7.jp/MT/archives/001197.html
ボーイング787で発生した問題
https://jp.reuters.com/article/boeing-787-idJPKBN0NM2Y420150501
  • 497日問題
Windows Vista、7、2008、2008R2で発生した問題
https://social.technet.microsoft.com/Forums/ja-JP/f77845e1-78fa-49de-90f3-e81f330671aa/497?forum=Wcsupportja
Linuxで発生した問題
http://tak-lab.net/2015/07/linux-uptime%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89-497%E6%97%A5%E5%95%8F%E9%A1%8C/
  • 776日問題*3
Windowsのパフォーマンスカウンタで発生する問題
https://technet440.rssing.com/chan-6827930/article29715.html
  • 828日問題
CISCOのスイッチで発生した問題
https://supportforums.cisco.com/ja/document/131876
IBMの外部ストレージで発生する問題
http://www-06.ibm.com/jp/domino04/pc/support/Sylphd07.nsf/jtechinfo/SYJ0-04D29E6 ↑webarchive
https://web.archive.org/web/20130130232521/http://www-06.ibm.com/jp/domino04/pc/support/Sylphd07.nsf/jtechinfo/SYJ0-04D29E6
  • 994日問題*4
UNISYSのES7000で発生する問題
http://www.unisys.co.jp/news/061101_information.html
  • 1044日問題*5
AMD EPYC7002コアのCPUで発生する問題
https://pc.watch.impress.co.jp/docs/news/1506320.html
  • 1243日問題
HPのスイッチで発生した問題
http://h50146.www5.hp.com/products/networks/procurve/support/faqs/information_switch.html ↑WebArchive
https://web.archive.org/web/20110321021410/http://h50146.www5.hp.com/products/networks/procurve/support/faqs/information_switch.html
  • 1365日問題(32768時間問題)*6
HPが採用したsamsungSSDで発生した問題
https://pc.watch.impress.co.jp/docs/news/1222207.html
  • 4.5年問題(40000時間問題)*7
SanDiskOEM SSDでHPE製サーバや、Cisco製サーバ、Dell製サーバ等で発生した問題
https://support.hpe.com/hpesc/public/docDisplay?docId=a00097382ja_jp&docLocale=ja_JP
https://www.cisco.com/c/en/us/support/docs/field-notices/705/fn70545.html https://www.dell.com/support/kbdoc/ja-jp/000177640/
  • 7.99年問題(70000時間問題)*8
ToshibaOEM SSDでHPE社や、Fujitsuで発生した問題
https://support.hpe.com/hpesc/public/docDisplay?docId=a00111296ja_jp&docLocale=ja_JP
https://jp.fujitsu.com/platform/server/primergy/note/page40.html


違う問題として、n年問題がある。n年問題は2種類あって、西暦n年に問題が発生するもの、n年経過で問題が発生するものだ。以下はn年経過で問題が発生するものの例だ。n年問題の原因は「何らかの認証期限をn年と設定したとき、その設定年を超えてしまう」ことによっておこる。

  • 1年問題
Hyper-v2.0で発生した問題
http://devadjust.exblog.jp/14471809

西暦n年に発生する問題はWikipediaにまとまっているので参考にするとよいだろう

  • 西暦n年問題
https://ja.wikipedia.org/wiki/%E5%B9%B4%E5%95%8F%E9%A1%8C


まあ、これからも同様の問題は出てくるだろう。根本的な解決方法について前者は「カウンタを64bitにすること*9」、後者は「n年後に日付変更してテストすること」しかないと思われる。それにつけても、影響が大きい割に対応方法が「年一回の再起動」しかないIBMはゴミだ。

*1: (256^6/2) / (32*10^6) / 86400 →50.9日

*2:2022/10/24追記

*3:2022/10/31追記 よくわからないが2^26秒経過で発生するので、32bitのカウンタで1/64秒(1/2^6秒)をカウントしているのかも

*4:2016/3/26 追記

*5:2023/9/2 追記 原因がよく分からないけれど208.5日問題のちょうど5倍っぽいので、TSCのカウンタ初期化周りな気がします。

*6:2019/12/4追記

*7:2024/4/7追記

*8:2024/4/7追記

*9:ただし64bitだからと言って油断しないこと。208.5日問題は64bitで発生