A.masterhostは書き込みを続けました...
まず第一に、正直なパイオニアです。彼のトリックがなければ、この大きなプロバイダーに対しては何もありませんでした。 しかし、これは現場からの報告の続きです（私たちの「友情」の全容は少し後に公開されます）。
何がありますか。
これらのすばらしい人々から1台のサーバーをレンタルし、管理費を支払います。 ちょうどそう-それは腺についての頭を傷つけることはなく、誰が責任を負うかを見つける必要はありませんでした-Vasyaは管理者またはプロバイダーです。 いずれにせよ、プロバイダーへのすべての質問。
手紙が届きます：
データベースクエリXXXXXXX createが増加しました
MySQLサーバーの負荷。 そのようなクエリの例を示します。
添付ファイル内。
このようにスクリプトを最適化してください
サーバー全体のパフォーマンスに悪影響を及ぼします。
そして、もちろん、攻撃のクエリの例（基本的に-「select * from xxx where X = 'Y'」、テーブルxxxは3つのIntで、数十万レコードのインデックスがあります）。
このデータベースサーバーが誰であるのか、どこから来たのか、マシンではなくリクエストが実行された理由を尋ねると、答えが返ってきます。仮想サイトは、標準の共有ホスティングサーバーを使用します。
すべて最高。
そして、これが本当に私たちを悩ませないという事実についての私の手紙に応えて、 私たちは彼らのデータベースサーバーを使うように頼みませんでした、そして私たちのリクエストは私たちのローカルの問題です負荷が増加すると、データベースへのアクセスをブロックせざるを得なくなります。
...これらは子猫と一緒のパイです。
感情的でわかりにくい場合は、すみません。具体的に説明します。
PS：愛好家がしつこいと慣性を非難する-このプロバイダーからすべてのさを取り除くには、かなりの準備作業（ほぼ完了）と移動自体にかなりの時間を要すると言えます。 したがって、彼らは衰退していません。
upd：問題は解決され、クライアント管理部門の長から直接、サポートエンジニアから手紙が届きました。 このサイトは共有ホスティングと本当に混同されていたため、報復の脅威にさらされていました
Source: https://habr.com/ru/post/J9396/
All Articles