Windows 11と10で動作を遅くしていると指摘されるスタートメニューのWeb検索を無効化する方法は？
Windows 11ではスタートメニューの検索バーで、Windows 10ではスタートアイコン横の検索ボックスか検索アイコンで、PC内を検索して一致する結果を呼び出すことができます。しかしこの時、同時に入力したキーワードでBingのWeb検索候補も表示されるため、検索結果が表示されるまで数秒待つ必要があります。テクノロジー系メディアのTom's Hardwareの編集長であるアブラム・ピルチ氏が、WindowsのWeb検索機能を無効にするための操作について解説しています。 How to Disable Windows Web Search and Speed Up Your PC | Tom's Hardware https://www.tomshardware.com/how-to/disable-windows-web-search Windows 11でWindowsキーを押して「g
ジョブのブックマークを使用した処理済みデータの追跡 - AWS Glue
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 ジョブのブックマークを使用した処理済みデータの追跡 AWS Glue ではジョブの実行による状態情報を保持することで、ETL ジョブの以前の実行中にすでに処理されたデータを追跡します。この継続状態の情報はジョブのブックマークと呼ばれています。ジョブのブックマークは、AWS Glue で状態情報を保持して、古いデータを再処理しないために役立ちます。ジョブのブックマークを使用すると、スケジュールされた間隔で再実行する際に新しいデータを処理できます。ジョブのブックマークは、ソース、変換、ターゲットなど、さまざまなジョブの要素で構成されています。例えば、ETL ジョブが Amazon S3 ファイルで新しいパーティションを読み込むとします。AWS Glue は、そのジョブに
Amazon DynamoDB で AWS Lambda を使用する - AWS Lambda
Lambda 関数以外のターゲットにデータを送信したい、または送信する前にデータをエンリッチしたいという場合は、「Amazon EventBridge Pipes」を参照してください。 AWS Lambda 関数を使用して、Amazon DynamoDB ストリームのレコードを処理します。DynamoDB Streams では、Lambda 関数を使用して、DynamoDB テーブルが更新されるたびに追加の作業を実行することができます。 Lambda はストリームからレコードを読み取り、関数を、ストリームレコードを含むイベントと共に同期的に呼び出します。Lambda はバッチ単位でレコードを読み取り、関数を呼び出してバッチからレコードを処理します。 { "Records": [ { "eventID": "1", "eventVersion": "1.0", "dynamodb": { "
Amazon EC2 Auto Scaling とは - Amazon EC2 Auto Scaling
Amazon EC2 Auto Scaling は、アプリケーションの負荷を処理するために適切な数の Amazon EC2 インスタンスを利用できるようにします。Auto Scaling グループと呼ばれる EC2 インスタンスの集合を作成します。各 Auto Scaling グループ内のインスタンスの最小数を指定することができ、Amazon EC2 Auto Scaling グループはこのサイズよりも小さくなることはありません。各 Auto Scaling グループ内のインスタンスの最大数を指定することができ、Amazon EC2 Auto Scaling グループはこのサイズよりも大きくなることはありません。グループの作成時、またはそれ以降の任意の時点で、希望するキャパシティーを指定した場合、Amazon EC2 Auto Scaling によって、グループのインスタンス数はこの数に設
の Amazon RDS DB インスタンス設定を使用した Amazon ElastiCache キャッシュの作成 - Amazon Relational Database Service
ElastiCache は、フルマネージドのインメモリキャッシュサービスであり、マイクロ秒単位の読み取り/書き込みレイテンシーを提供し、柔軟なリアルタイムユースケースをサポートします。ElastiCache は、アプリケーションとデータベースのパフォーマンスを向上させるのに役立ちます。ElastiCache は、ゲームのリーダーボード、ストリーミング、データ分析など、データの耐久性を必要としないユースケースのプライマリデータストアとして使用できます。ElastiCache は、分散コンピューティング環境のデプロイと管理に関連する複雑さを排除するのに役立ちます。詳細については、Memcached の場合「ElastiCache の一般的なユースケースおよび ElastiCache がどのように役立つか」を、Redis の場合「ElastiCache の一般的なユースケースおよび Elasti
Amazon CloudWatch メトリクスを使用した AWS Glue のモニタリング - AWS Glue
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon CloudWatch メトリクスを使用した AWS Glue のモニタリング AWS Glue ジョブプロファイラーを使用して AWS Glue オペレーションをプロファイルおよびモニタリングできます。AWS Glue ジョブから raw データが収集され、ほぼリアルタイムの読み取り可能なメトリクスに加工されて、Amazon CloudWatch に保存されます。これらの統計は CloudWatch に保持されて集計されるため、履歴情報にアクセスしてアプリケーションの動作をより的確に把握できます。
Horizontal Pod Autoscaler - Amazon EKS
Kubernetes Horizontal Pod Autoscaler は、そのリソースの CPU 使用率に基づいて設定されたデプロイ、レプリケーションコントローラー、またはレプリカセット内の Pods の数を自動的にスケーリングします。これにより、アプリケーションは需要の増加に合わせてスケールアウトしたり、リソースが不要になったときにスケールインしたりできるため、ノードを他のアプリケーションに解放できます。ターゲットの CPU 使用率を設定すると、Horizontal Pod Autoscaler はターゲットを満たすようにアプリケーションをスケールインまたはスケールアウトします。 Horizontal Pod Autoscaler は、Kubernetes の標準 API リソースであり、動作するには、メトリクスソース (Kubernetes メトリクスサーバーなど) が Amazo
RDS の CPU 使用率がほぼ 100％ どう調査する？ 実例から学ぶ原因と解決策 〜オペ部だより〜 | DevelopersIO
こんにちは、札幌在住 AWS 事業本部 オペレーション部（通称オペ部）の池田です。オペ部ではクラスメソッドメンバーズにご加入いただいているお客様が直面されたお困りごとや疑問など、様々なお問い合わせに対して各種ドキュメントや技術検証結果のご案内をしたり、場合によっては AWS と連携してお客様が直面している問題解決の支援を行なっています。 本記事では、タイトルにある通り実際にいただいた「RDS の CPU 使用率が（ほぼ）100％ 何が原因なの？」というお問い合わせの中から、代表的な事例とその調査方法をご紹介したいと思います（今回も全ての事例を網羅できているわけではありませんが、調査方法の参考にしていただけると嬉しいです）。 はじめに RDS の CPU 使用率が 100% あるいは ほぼ 100% となる原因は実に様々です。そもそも選択したインスタンスのスペックが低すぎる場合、設計上想定し
RDS for MySQL または Aurora MySQL の CPU 使用率が高い場合のトラブルシューティング
注:Amazon RDS では、DB インスタンスで実行されている他のタスクよりもワークロードの優先度が高くなります。これらのタスクに優先順位を付けるには、ワークロードタスクの ** Nice 値を高くします。そのため、拡張モニタリングでは、 Nice% ** はワークロードがデータベースに対して使用している CPU の量を表します。 拡張モニタリングを有効にすると、DB インスタンスに関連付けられている OS プロセスリストも確認できます。拡張モニタリングには、最大 100 のプロセスが表示されます。これにより、CPU とメモリの使用量に基づいて、パフォーマンスに最も大きな影響を与えるプロセスを特定できます。 拡張モニタリングのオペレーティングシステム (OS) ** プロセスリストセクションで、 OS ** プロセスと ** RDS ** プロセスを確認します。mysqld プロセスま
S3 Intelligent-Tiering の仕組み - Amazon Simple Storage Service
Amazon S3 Intelligent-Tiering ストレージクラスは、3 つのアクセス階層に自動的にオブジェクトを保存します。1 つの階層は高頻度アクセス用に最適化され、1 つの低コスト階層は低頻度アクセス用に最適化されます。またもう 1 つの極めてコストの低い階層は、ほとんどアクセスされていないデータに最適化されます。オブジェクトのモニタリングおよびオートメーションにかかる月額料金を抑えるために、S3 Intelligent-Tiering はアクセスパターンをモニタリングし、30 日間連続してアクセスがなかったオブジェクトを、低頻度アクセス階層に自動的に移動します。90 日間アクセスされていない場合に、オブジェクトはパフォーマンスへの影響や運用上のオーバーヘッドなしで、アーカイブインスタントアクセス階層に移動されます。 数分から数時間でアクセスできるデータのストレージコストを
DynamoDB Auto Scaling によるスループットキャパシティの自動管理 - Amazon DynamoDB
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 DynamoDB Auto Scaling によるスループットキャパシティの自動管理 多くのデータベースワークロードは本質的に循環的なものであり、前もって予測することが困難なものもあります。例えば、日中の時間帯に大部分のユーザーがアクティブなソーシャルネットワーキングアプリがあるとします。データベースは日中のアクティビティを処理できる必要がありますが、夜間のスループットに同じレベルは必要ありません。別の例としては、予想以上に急速に普及した新しいモバイルゲームアプリが挙げられます。ゲームがあまりに人気になると、利用可能なデータベースリソースを超過し、パフォーマンスが低下して顧客が不満を感じるようになります。この種のワークロードでは多くの場合、手動介入によってデータベー
テーブルキャパシティモードの評価 - Amazon DynamoDB
このセクションでは、DynamoDB テーブルで、適切なキャパシティモードを選択する方法の概要を説明します。各モードは、スループットの変化に対する応答性や使用に対する請求方法という点で、さまざまなワークロードのニーズを満たすように調整されています。決定を下す際には、これらの要素のバランスを取る必要があります。 利用可能なテーブルキャパシティモード DynamoDB テーブルを作成する場合、オンデマンドまたはプロビジョンドキャパシティモードのいずれかを選択する必要があります。24 時間ごとに 1 回、読み込み/書き込みキャパシティモードを切り替えることができます。唯一の例外は、プロビジョンドモードテーブルをオンデマンドモードに切り替えた場合、同じ 24 時間以内にプロビジョニングモードに戻すことができることです。 オンデマンドキャパシティモード オンデマンドキャパシティモードは、Dynamo
パフォーマンスに影響！Redshiftのテーブル設計時に最低限意識すべきポイント3選
Introduction AWSが提供するDWHサービス、Amazon Redshift。 全世界での採用企業は数万社を超えており、弊社も国内において多くのお客様に導入のご支援をさせて頂きました。 RedshiftはAWSエコシステムとの親和性が高く、AWSを既にご利用のお客様は導入の敷居が低いDWHサービスとなっております。 しかし、適切なテーブル設計を行わなければパフォーマンスを全く発揮できません。 不適切なテーブル設計をしてしまったが故、「バッチ処理が当初想定していた時間で終わらない」等、弊社にご相談頂いたお客様も数多くいらっしゃいます。 では、Redshiftを扱うにあたってどのようなテーブル設計を行えば良いのか。 本記事では、パフォーマンスの向上に繋がるテーブル設計のポイントを3つ、ご紹介致します。 1. ソートキー（SortKey） ソートキー（SortKey）は、テーブルのデ
Amazon Redshift 分散キーの変更について試してみた | DevelopersIO
分散キー変更の際にVACUUMを実行する必要が不要になったというリリースを目にしました。正直、ALTERにて分散キーの変更が可能になったことに気づいていませんでしたので、この機会に分散キーの変更について試してみました。マニュアルに記載にない動作も確認できましたのでご紹介したいと思います。試したクラスタバージョンは、1.0.11116です。 Cluster Version History - Version 1.0.10013, 1.0.10221, 1.0.10393, 1.0.10480, or 1.0.10648 の抜粋です。 The ALTER TABLE ALTER DISTKEY command for tables with a sort key now performs an inline sort. Therefore, running VACUUM afterwards
Athena でのパフォーマンスのチューニング - Amazon Athena
このトピックでは、Athena クエリのパフォーマンスを向上させるための一般的な情報と具体的な提案、および制限やリソース使用量に関連するエラーの回避方法について説明します。 Service Quotas Athena では、クエリ実行時間、アカウント内の同時クエリ数、API リクエスト率などの指標に対してクォータを適用しています。これらのクォータの詳細については、「Service Quotas」を参照してください。これらのクォータを超えると、送信時またはクエリ実行中にクエリが失敗します。 このページのパフォーマンス最適化の多くのヒントは、クエリの実行時間を短縮するのに役立ちます。最適化によって容量の制限がなくなり、同時実行クォータ内でより多くのクエリを実行できるようになり、実行時間が長すぎたためにクエリがキャンセルされるのを防ぐことができます。 同時実行クエリと API リクエストの数のク
同時実行スケーリングを使用する - Amazon Redshift
同時実行スケーリング機能を使用すると、一貫した高速のクエリパフォーマンスで、数千の同時ユーザーと同時クエリをサポートできます。 同時実行スケーリングが有効になっている場合、Amazon Redshift は自動的に新たなクラスターキャパシティーを追加し、読み取りと書き込み両方でクエリの増加に対応します。クエリをメインクラスターと同時実行スケーリングクラスターのどちらで実行しても、ユーザーには最新のデータが表示されます。同時実行スケーリングクラスターは、実際に実行した時間分のみ課金されます。料金の詳細については、Amazon Redshift 料金表を参照してください。 WLM キューを設定することで、どのクエリを同時実行スケーリングクラスターに送信するかを管理します。同時実行スケーリングを有効にすると、対象となるクエリはキュー内に待機することなく、同時実行スケーリングクラスターに送信される
ワークロード管理の実装 - Amazon Redshift
ワークロード管理 (WLM) を使用して複数のクエリキューを定義し、実行時にクエリを適切なキューに配信することができます。 複数のセッションやユーザーが同時にクエリを実行している場合があります。このような場合、一部のクエリがクラスターリソースを長時間消費して、他のクエリのパフォーマンスに影響を与えることがあります。例えば、あるユーザーグループが、複数の大規模なテーブルの行を選択して並べ替える、実行時間の長い複雑なクエリをときどき送信するとします。別のグループは、1 つまたは 2 つのテーブルから数行のみを選択し、数秒実行される短いクエリを頻繁に送信します。この状況では、実行時間が短いクエリは、実行時間が長いクエリが完了するまでキューで待機しなければならない場合があります。WLM は、このソリューションの管理に役立ちます。 Amazon Redshift WLM は、自動 WLM または手動
DynamoDB Accelerator (DAX) とインメモリアクセラレーション - Amazon DynamoDB
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 DynamoDB Accelerator (DAX) とインメモリアクセラレーション Amazon DynamoDB はスケールとパフォーマンスのために設計されています。ほとんどの場合、DynamoDB の応答時間は 1 桁台のミリ秒単位で測定できます。ただし、マイクロ秒の応答時間を必要とする一部のユースケースがあります。これらのユースケースでは DynamoDB Accelerator (DAX) が整合性データへのアクセス時に素早い対応を実現します。 DAX は、DynamoDB と互換性のあるキャッシュサービスで、条件の厳しいアプリケーションで高速なインメモリパフォーマンスを可能にします。DAX は、次の 3 つのコアシナリオに対応します。 インメモリキャッシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Developers Summit 2024フォローアップ】『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～
Amazon.co.jp: プログラマーのためのCPU入門 CPUは如何にしてソフトウェアを高速に実行するか: Takenobu Tani: 本
