メインコンテンツへスキップ
サインイン

SQL Server の再起動

nkmt

お世話になっております。
SQL Server StandardをオンプレミスのWindowsサーバーへインストールしている所があり

ある客先でSQL Serverをタスクスケジューラで毎日再起動しているようでした。

・SQLServer Management StudioでSQLサーバーが使うメモリ容量の上限を決める。

・ターミナルサーバーも兼用していれば、切断セッションは終了させる。

の２点を行えば、SQL Serverの再起動は不要だと思っております。

SQL Serverが際限なく搭載メモリを食いつぶす状況だったので、SQL Serverを再起動する
タスクを組み込んでいたのだと思われます。
せっかくのキャッシュが無駄になり、毎日キャッシュし直す仕事が生じて余計な仕事をサーバーが

せねばならぬと思いますが、考え方が間違えておりましたらご指摘頂けますと幸いです。

コメント

20件のコメント

日付 投票
  • Ｐｕ

    こんにちはＰｕです

     

    よっぽど古いSQLSERVERでない限りSQL OSがメモリー管理しているので

    SQLSERVERの再起動しなくても良いと思います。

    それよりWindowsUpdateを長い間しないとメモリーリークが激しくなるので

    その為OSの再起動の方が必要となる確率が高いです。

    でわ～でわ～

  • Tanda

    SQLServerは枯れたバージョンと枯れていないバージョンとで、かなりパフォーマンスの最適化に優劣があるようですので、私はなるべく枯れたバージョンで検証するようにしています。特に、CPU使用率の問題は、枯れているかいないかで顕著な違いがあるようです。

  • nkmt

    大御所御三方ありがとうございました。
    CPU使用率はTandaさんからお聞きしますが、あまり同じシーンに遭遇した事はありません。

    SQL Server製品版は、2008がまだ１件ありますが、2012、2016、2017等を使用しております。

    SQL Serverが一生懸命仕事をしているのですかね。
    Magicの従来作りでは、何度もSQL文を発行するのに対し、従来作りであっても外部リンクを有効活用する手も

    ありますが、CPU負荷率を弱く×長く使うとCPU使用面積に例えると広大にCPUを使ってしまう。
    SQL文でJOINやGROUP BYを使うといった事をすれば一瞬ピークは高いけど、ネットワークに流れるデータ量も

    抑えられ、CPU使用面積は少なくて済む。アプリ側でデータの集計はしないといった点が本に書いてありました。
    SQL多用してとても重宝しております。フォーラムに書くのは５回目ぐらいかもしれません。

    WindowsサーバーOSのUpdateと再起動を計画的にしていないので、月１で施すなどした方がいいのでしょうね。

  • Tanda

    CPU使用率は、デュアルコア以上のCPUですとあまり表には出てこないのですが、裏では1つのCPUを占有してしまっているというような症状になることがありますね。個々のCPUを細かくモニタリングしていると分かることがあります。

  • nkmt

    MDFは6.5GBありまして、サーバー搭載メモリは16GBあります。

    その客先はターミナルサーバーは担っておらず、DBサーバーですね。

    SQL Serverのメモリ上限の設定もSQL Serverの数日おきの再起動さえも要らぬ気がします。
    CPU使用率はあまり気にした事がないので、CPUモニターのタブも見てみます。

  • nkmt

    おそらく旧サーバー時代、メモリも8GB時代は、よくメモリ使用率90％などになっており、SQL Serverメモリ使用上限設定も知らなかったといった事があり、SQL Serverを定期的再起動タスクを入れていたのかもしれません。

  • Ｐｕ

    こんにちはＰｕです。

    WindowsServer OSとSQL OSとは密に連携し最適なメモリー管理をするように設計されています。

    （MSがそういうアークテクチャーでSQLserverを作成しているのですが

    実際はわかりませんが^^）

     

    ですのでSQLSERVERのメモリーに関してチューニングは必要ないです

    お金の許す限り積んで下さい。

    メモリーリークや使用量が100%のまま下がらないのは他の要因であることがほとんどです。

    でわ～でわ～

     

  • nkmt

    メモリ16GBで、MDFが6.5Gといった容量でSQL Server Stdなのに

    SQL Serverを毎日再起動とか3日おきに再起動とか面白い設定をしているなと思いました。

    私が関わる関わる所は小規模が多いので、16GBなどで十分なところが多いです。

    数年前はWin2012搭載富士通サーバーが特価5万円ぐらいで売っていて（PCにけが生えたような物）

    それを4台まとめ買いしている営業さんがいたり面白かったです。

    増設して、メモリ20GBとか中途半端だけど積みすぎとか。

    なのに動いているDBはSQL Server Expressとか。それだけサーバーが安ければオンプレミスで

    メインサーバーとバックアップサーバーにして、毎日、BAT処理でDBレプリカを作成しておりました。

  • nkmt

    昨日か一昨日からあるお客様でSQLサーバー2012スタンダードなのにメモリを500メガバイトぐらいしか使用していない症状が出ました。
    Windows2012でシステムの回復、復元がどこにあるのかわからず、別件もあり担当者さんに託し中。

  • nkmt

    このお客様はメモリを20ギガバイトも積んでますが、今は15％しか使ってませんでした。原因が不明です。

  • nkmt

    朝はSQL Serverのメモリは　コミット564ＭＢでしたが

    今は1.14ＧＢになりました。

  • nkmt

    ・オープンできません.データソース: MST商品

     

    ・[DBNETLIB][ConnectionRead (recv()).]一般的なネットワーク エラーです。ネットワークのマニュアルを調べてください。

     

    ・SQLコマンドが正しくありません.データベース.: MSSQL2012, program: 売上伝票入力

     

    などが　mgerro.log　に記載されています。

     

    明日は現地へ行ってきます。

  • nkmt

    PING   192.168.1.8  －t　を実行しても

    1ms　TTL=128ですね。２分ぐらい実行。

  • Ｐｕ

    こんにちは　Ｐｕです

     

    私もサーバーが再起動したような気がします。

    再起動後のSQLserverの使用メモリーは最小になり

    起動時間（クエリーの処理数）が長くなると、実行計画をキャッシュに保存したりするので

    メモリーを消費していきます。

    でわ～でわ～

     

  • nkmt

    ISHJIMA様、Puさん、ありがとうございます。

    8/18ぐらいから販売管理が不調なようです。クラサバです。

    販売管理を起動した状態で、Win10からサーバーにPING -t をすると

    タイムアウトする時があるとの事でした。

     

  • nkmt

    ISHJIMA様　ありがとうございます。

    今日はネットワークの方もお見えになるので、一緒に原因究明したいと思います。

    xpa3.2のパッチも何かないか見てみたいと思います。


    私のプログラムが悪さしているかもしれません。

    別のシステムですが、売上明細で商品コードを入力したら、代入式に設定した

    売値計算式で自動再計算多発で重いといった事もありました。

  • nkmt

    その別件の以前の不具合の時は

    商品コード入力 → 商品マスタ → 商品群マスタ → 掛率設定、単価マスタなどなど

    などなどその売値計算の元になるパラメータが商品コード、得意先コード、現場コード、

    数量、明細で入力した掛率など、１個入力を変えると、再計算によりデータ取得が多重発生しておりました。

    ちなみにxpa3.2ではなく3.1aでした。

    TeamViewerでこちらから現地サーバーを見ても、接続が失われました、再接続中ですと出ますし、

    mgerror.logにも　オープンできません　DATA○○伝票とか出てますね。

     

    クライアントPCのWin10かhubかLANケーブルか、サーバーのLANポート不調か。

     

     

     

  • nkmt

    ３日ぐらい前から販売管理が遅いとか固まると聞いていたお客様先へ行ってまいりました。

    結果としては、遅い固まるはなくなりました。解決と言えます。
    （WindowsUPDATEによりものなのかとか、昨日までいろいろとリモートで点検。）

    現地で障害が生じるPCで販売管理システムの操作を行い、少し重い絞り込みなどをすると
    PING -tでタイムアウトがよく発生しました。でもそれ以外のPCはサクサク動くというのを発見。


    なぜ該当PCは不調なのだろうか？（このPCだけギガで、他は100Ｍ LAN）


    該当PCのLANケーブルを100M HUBにつないだ所、改善したかに見えましたが、
    またDB接続エラーなどが生じました。


    サーバーのLANポートがもう一つあるのでそっちも試してみましょうという事になり、
    そっちを有効にしてIPアドレスも設定。
    その結果、販売管理も固まる事もなくなりました。タイムアウトも無くなりました。


    その富士通のサーバーはLANポート２つのドライバが違うものでした。


    ISHIJIMA様、Puさん、アドバイスなどありがとうございました。

  • nkmt

    おはようございます。

    片方のLANはメンテナンス用ポートの機種があるという話は私は知らなかったのですが

    他の方も「そういえば・・・」と同じ事はおっしゃっていました。

    月曜日以降、その辺りも調べてみたいと思います。


    そのサーバーでの販売管理でこの４年間固まったりDB接続エラーが生じる事はなく

    8/18から遅くなり、8/19に連絡を受けリモートでリソースモニタ、イベントビュアーを

    見て、お客様のサーバーを見ている方とも、WindowsUPDATEが悪さをしたのですかねとか

    そちらを疑っておりました。

     

    その会社様のネットワーク構築は別業者さんが行っているのですが、よく固まる機種だけが

    壁コンセントからギガで接続している、他のＰＣではさくさく動く、ギガPCだけが不調、

    なぜだ、LANケーブルつなぎなおせ、直ったかに見えた、いや直らない、サーバーのポートを

    替える案もその日朝から案としてはあったので実際にやってみたら販売管理を起動しても

    ping -t でタイムアウトも無くなり結果オーライでした。

     

    サーバーのLANポート、ドライバ？が不調でそこにギガで重いリクエストが来てサーバーが

    不調をきたしていたのか・・・と予想したにすぎません。原因追及までには及びませんでした。

     

    サーバーのLANポートのドライバも更新されて不具合が起きたのかもしれません。

     

    ネットワーク屋さんと営業会社さんは、公開サーバーでもないので、UPDATEはしばらく

    （いやずっと）止めませんか？との事でしたので、そうすることになりました。

     

    別のお客様のDELLのサーバーをリモートで拝見しましたが、ドライバは同じものでした。
    富士通のサーバーは

    ・Intel Ethernet Connection I1217-LM と

    ・Intel 1210 Gigabit Network Connection でした。

  • Tanda

    > 関係ないかもしれませんが・・・

    関係あると思いますよ。ハブに限らず、10baseや100baseのケーブルが1本でも混在しただけでトラブルことが多々あります。

    昔はケーブルも値段が高かったですから、捨てるのに忍びないことがあるんですよね。笑

サインインしてコメントを残してください。

お探しのものを見つけられませんでしたか？

新規投稿