「ちゃんとやるだけ」大規模ECサイト（その７）
すみません。しばらく間が空いてしまいました―――
というワケで前回。
「購入直後のクエリキャッシュクリアによるクエリ生成の大渋滞」を解消する為、
あえてクエリでJOINしないことで大渋滞は解消されたのですが…
ＤＢサーバの不可は解消されたものの、今度はWebサーバの負荷が急上昇。
実行しているクエリの処理時間を確認してみたが流石に問題なし。
MRTGでＤＢの負荷を確認すると以前とは打って変わって静かなもの。
では、今回は一体何故…と原因を調査していたら、
サーバ管理者から「swapメモリ食い潰してます」との報告。
それを聞いて、ソースを見直してみたところ…そりゃ、確かに食い潰しますわ。
先の対処でDBのJOINをやめる為、
その代わりにメモリ上に各々のテーブルを配列として持っておいて、
ＣＧＩ側の処理内でデータ連結させてたのですが―――
メモリ上に持っておく各テーブルのデータが大き過ぎたという話。（＊万件は流石にダメだろ自分…）
データ絞り込む手順を変えたらアッサリ直りました。
切羽詰った状況で「解消すべきポイント」が見つかって、そこに勢いよく突っ込んでいると、
いつも「ちゃんと」できていたことを見失いがちになってしまう…と。
直接「大規模」とは関係ないかもしれませんが、
データ量がデータ量なら、しばらく気づかなかったかもしれないので…
己への戒めという意味で書かせていただきました。
というワケで、リリースからしばらくの間。
「EC-CUBE」＋「EC-CUBEではあまり前例にないデータ量とトラフィック」に振り回されてきましたが、
先の対処でひとまずサーバ負荷的には安定しております。（特にＤＢは静かなもので）
ただ時が経つにつれ、データ量，トラフィックが自然増加を続けており、
特にWebサーバから外向きのトラフィック量については好調な企業の株価の如く。
というワケで今の内から何らかの対策を検討しておく必要が…と、いってる側から。
実は少し前、今回記述した対処から約半年。Webサーバの負荷が、再び増えたことがありました。
次回は、その辺りのお話。
というワケで前回。
「購入直後のクエリキャッシュクリアによるクエリ生成の大渋滞」を解消する為、
あえてクエリでJOINしないことで大渋滞は解消されたのですが…
ＤＢサーバの不可は解消されたものの、今度はWebサーバの負荷が急上昇。
実行しているクエリの処理時間を確認してみたが流石に問題なし。
MRTGでＤＢの負荷を確認すると以前とは打って変わって静かなもの。
では、今回は一体何故…と原因を調査していたら、
サーバ管理者から「swapメモリ食い潰してます」との報告。
それを聞いて、ソースを見直してみたところ…そりゃ、確かに食い潰しますわ。
先の対処でDBのJOINをやめる為、
その代わりにメモリ上に各々のテーブルを配列として持っておいて、
ＣＧＩ側の処理内でデータ連結させてたのですが―――
メモリ上に持っておく各テーブルのデータが大き過ぎたという話。（＊万件は流石にダメだろ自分…）
データ絞り込む手順を変えたらアッサリ直りました。
切羽詰った状況で「解消すべきポイント」が見つかって、そこに勢いよく突っ込んでいると、
いつも「ちゃんと」できていたことを見失いがちになってしまう…と。
直接「大規模」とは関係ないかもしれませんが、
データ量がデータ量なら、しばらく気づかなかったかもしれないので…
己への戒めという意味で書かせていただきました。
というワケで、リリースからしばらくの間。
「EC-CUBE」＋「EC-CUBEではあまり前例にないデータ量とトラフィック」に振り回されてきましたが、
先の対処でひとまずサーバ負荷的には安定しております。（特にＤＢは静かなもので）
ただ時が経つにつれ、データ量，トラフィックが自然増加を続けており、
特にWebサーバから外向きのトラフィック量については好調な企業の株価の如く。
というワケで今の内から何らかの対策を検討しておく必要が…と、いってる側から。
実は少し前、今回記述した対処から約半年。Webサーバの負荷が、再び増えたことがありました。
次回は、その辺りのお話。
