33_redis実際のいくつかの一般的な問題と最適化のアイデア(Linuxカーネルパラメータの最適化を含む)


基本的に、これまでは誰もが直接会社に行き、redisを構築できます。

一部のパラメータの設定など、実際には詳細を説明できないものがあるため

さまざまな企業、さまざまなビジネス、さまざまな量のデータには、調整すべきさまざまなパラメーターがある場合があります

これまでのところ、このアイデアによれば、高い同時実行性、高可用性、大規模なデータアーキテクチャ、デプロイメントをサポートするredisを構築するために、誰もがほぼ同じです

会社の既存のデータの一部を使用して、それをインポートし、数百万、1000万、入力できます。

さまざまなストレステスト、パフォーマンス、redisベンチマーク、同時実行性、QPS、高可用性ドリル、各マシンに保存できるデータの量、およびより多くのデータをサポートするための水平方向の拡張を実行します

テスト環境とテストデータに基づいて、さまざまな演習を行って、最適な詳細のいくつかを調べます

あなたは、技術的に不可能であるすべてのものを得るためにコースのセットに依存していると言いました。

マスターがドアをリードし、練習は個人的なものです

優れたコースの唯一の基準は、この価格で、他の場所からは学べない、価格に見合うだけのテクノロジーとアーキテクチャを教えることができるか、または自分で学ぶのに数回かかるということです。タイム模索

このコースの価値は

あなたは数百ドルを費やし、コース、要件、コースを購入し、学習した後、すぐに孤独な剣であり、会社に直接あらゆる種類の問題を簡単に解決できると言いました

この世界には、そのようなカリキュラム、合理的な価値はなく、誰もが非常に良性のインタラクティブなプロセスを持つことができます

スパークなどのコース

プロジェクトを行うためのコースを実際に学んでいると、予想外の問題が100%発生します。遭遇した場合は、まず解決に努めます。問題が発生した場合、それは経験の蓄積です。

問題が発生し、QQを追加してから、私に相談します。これから説明します。それも可能です。

spark、elasticsearch、javaアーキテクチャコース

質問の70%から80%、私はあなたがそれを得るのを手伝うことができます、私はそれをすることができます

1.フォークに時間がかかるため、同時リクエストの遅延が大きくなる

RDBとAOFの場合、実際には、RDBスナップショット、AOF書き換え、ディスクIO消費、メインプロセスフォークの子プロセスを生成するプロセスがあります。

forkするとき、子プロセスは親プロセスのスペースメモリページテーブルをコピーする必要があります。これにも一定の時間がかかります

一般的に言って、親プロセスに1 Gのデータがある場合、フォークは約20ミリ秒かかります。10G〜30Gの場合、20 * 10、20 * 30でさえ数百ミリ秒かかります。

info statsのlatest_fork_usec、最後のフォームの期間を確認できます

RedisスタンドアロンQPSは一般的に数万であり、フォークによって一度に数万のオペレーションのリクエスト時間が数ミリ秒から1秒に遅くなる場合があります

最適化のアイデア

時間のかかるフォークは、redisマスタープロセスのメモリに関連します。一般的に、redisのメモリは10GB以内で制御されます、スレーブ->マスター、フルコピー

2. AOFのブロッキング問題

RedisはデータをAOFバッファーに書き込み、毎秒1回、fsync操作用に別のサイトを開きます

しかし、redisのメインスレッドはfsyncの時間を2回チェックします。最後のfsync時間が2秒を超えると、書き込みリクエストはブロックされます

毎秒、最大2秒のデータが失われる

fsyncが2秒の遅延を超えると、redis全体の速度が低下します

最適化のアイデア

ハードディスクの書き込み速度を最適化します。SSDを使用することをお勧めします。通常の機械的なハードディスク、SSDは使用せず、ディスクの読み取りと書き込みの速度を大幅に向上させます。

3.マスター/スレーブレプリケーションの遅延

マスター/スレーブレプリケーションは深刻にタイムアウトする可能性があり、この時間には適切な監視およびアラームメカニズムが必要です

情報レプリケーションでは、マスターレプリケーションとスレーブレプリケーションのオフセットを確認できます。違いを確認して、対応する遅延を確認してください。

遅延が多すぎる場合は、アラーム

4.マスター/スレーブレプリケーションストーム

複数のスレーブがマスターから一度にフルレプリケーションを実行できるようにすると、大きなrdbが同時に複数のスレーブに送信され、ネットワーク帯域幅が著しく占有されます。

マスターが本当に複数のスレーブをマウントしたい場合は、スター構造の代わりにツリー構造を使用してみてください

5、vm.overcommit_memory

0:十分なメモリがあるかどうかを確認します。そうでない場合、メモリの適用に失敗します
1:メモリが使い果たされるまでメモリの使用を許可します
2:メモリアドレススペースがswap + 50%を超えることはできません

0の場合、forkなどの操作が失敗する可能性があり、十分なメモリ領域が適用されません

cat / proc / sys / vm /
overcommit_memory echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
sysctl vm.overcommit_memory = 1

6、スワップ

cat / proc / version、Linuxカーネルのバージョンを確認する

Linuxカーネルのバージョンが3.5未満の場合、swapinessは0に設定されているため、システムはoom killerではなくスワップします(プロセスを強制終了します)
。Linuxカーネルのバージョン> = 3.5の場合、swapinessは1に設定されているため、システムはoom killerよりもスワップします。

redisが強制終了されないようにする

echo 0> / proc / sys / vm / swappiness
echo vm.swapiness = 0 >> /etc/sysctl.conf

7、最大のオープンファイルハンドル

ulimit -n 10032 10032

オンラインにして自分で検索します。オペレーティングシステム、バージョン、設定が異なります

8、tcpバックログ

cat / proc / sys / net / core / somaxconn
echo 511> / proc / sys / net / core / somaxconn

 

おすすめ

転載: www.cnblogs.com/hg-super-man/p/12742131.html