CPUの脆弱性、Linux関係者らの見方や対応
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 編集部 2018-01-05 14:57 Linuxは、プロセッサの脆弱性「Meltdown」「Spectre」の影響を緩和することはできるものの、Linux開発者たちがこの一件について不満を抱いていないわけではないだろう。Linuxカーネルの生みの親であるLinus Torvalds氏もLinuxカーネルのメーリングリスト（LKML）で以下のように述べている。 私は、Intel社内の人物が時間をかけて、自社CPUを厳しい目で精査する必要があると考えている。そして、すべてが設計通りに動作しているといった広報用の文章を作文するのではなく、問題があるという事実を実際に認める必要があるとも考えている。..またこのことは、問題を軽減するためのこれらパッチが「すべてのCPUがガラクタというわ
高負荷環境でDBが直面する問題とは？PHPとMySQLの TCP TIME-WAIT チューニング(前編) | さくらのナレッジ
サンプルサーバーのパケットフィルタは最初は以下の内容で設定し、セキュリティを確保しています。 tcp 22 はプライベートLANからの受信のみ許可 tcp 3306 は 153.127.195.113 のappサーバーだけに公開 tcp 80 は公開 tcp, udp の 32768-61000 はアウトバウンド通信の戻りパケット用に許可 ストリーミングのフラグメントパケットは公開 ip は基本拒否 また IP アドレスを打たずにホスト名でアクセス出来るように /etc/hosts に以下のエントリを追加しました。 153.127.195.113 app 153.127.203.176 db MySQLクライアントで接続して TCP の状態を観察 ここから実際にサーバーを動かして、その挙動を観察していきます。db サーバーに db1 データベースを作成し、アクセスユーザー user1 を追
Rails: PostgreSQLのマイグレーション速度を改善する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Better Database Migrations in Postgres 公開日: 2017/09/10 著者: Craig Kerstiens サイト: http://www.craigkerstiens.com/ データベースが成長してスケールするに連れ、気を遣わなければならない点が当初とは変わってきます。アプリをdev環境で動かしているうちは気にもかけていなかった操作コストを、production環境でがっつりと支払うはめになったりします。私たちの多くがやらかしてしまうのが、たとえばマイグレーションです。production環境でマイグレーションの起動に5分、それから15分間動き続けたまではよかったのですが、突然トラフィックに問題が生じたりします。 こういう事態を引き起こしがちな操作は2つありますが、どちらについてもダウ
SREによるモンスト改善事例 / improvement-example-of-monster-strike-by-sre
hbstudy#76 第76回： SRE大全: XFLAG スタジオ編 https://hbstudy.connpass.com/event/62338/
Amazon Redshift Spectrum クエリパフォーマンス - Amazon Redshift
explain select top 10 spectrum.sales.eventid, sum(spectrum.sales.pricepaid) from spectrum.sales, event where spectrum.sales.eventid = event.eventid and spectrum.sales.pricepaid > 30 group by spectrum.sales.eventid order by 2 desc; QUERY PLAN ----------------------------------------------------------------------------- XN Limit (cost=1001055770628.63..1001055770628.65 rows=10 width=31) -> XN Merge
MySQLの高可用性構成の展望2017年版 | Yakst
MySQL高可用性オプションについて3つパートで説明された記事。この記事では最初のパートThe Elders（長老たち）の技術を紹介している。 MySQLに比較的新参の人に向けて書かれており、「レプリケーション」「共有ストレージ」「NDB Cluster」の技術について、メリットとデメリットを説明している。 このブログでは、さまざまなMySQL高可用性オプションについて考察します。 ダイナミックなMySQLエコシステムは、MySQLを中心に構築された多くの技術を急速に進化させています。これは、MySQLの高可用性（HA）の側面に関連する技術に特に当てはまるでしょう。 私が2009年にPerconaに入社したとき、こういったHAの技術のいくつかは非常に人気がありましたが、それ以来ほとんどは忘れられています。その同じ期間で、新しい技術が登場しました。読者にいくつかの視点を提供しながら、出来れば
MySQLパフォーマンスチューニング -クエリキャッシュ適用状況の確認- - Qiita
花粉真っ盛り。 もれなく花粉症MAXな日々を過ごしております。 まみーです。 前回のエントリーからの続きになります。 MySQLパフォーマンスチューニング -my.cnfの見直し- 今回は、前回の設定結果の中から、クエリキャッシュの効き具合を測定・検証していきます。 概要 my.cnf に設定した内容のうち、クエリキャッシュについて検証します。 前回の設定変更から1週間経過した時点での値の比較となります。 目的 設定されていなかったクエリキャッシュが適切に効いているのかを検証し、設定が妥当かどうか判断します。 問題点 サービスの運用上、以下の問題点があります。 変更できない テーブル構成 リクエストごとに増え続ける ログレコード 必要な リアルタイム検索機能 状況 クエリキャッシュ設定前の状況は以下でした。 リアルタイム検索を 複数実行するとサーバーが落ちる 1プロセスでも 応答に30秒
カタログクエリの例 - Amazon Redshift
次のクエリは、カタログテーブルのクエリを実行して Amazon Redshift データベースに関する有益な情報を取得できるいくつかの方法を示しています。 テーブル ID、データベース名、スキーマ名、テーブル名の参照 次のビュー定義は、STV_TBL_PERM システムテーブルを PG_CLASS、PG_NAMESPACE、および PG_DATABASE システムカタログテーブルと統合し、テーブル ID、データベース名、スキーマ名、テーブル名を返します。 create view tables_vw as select distinct(stv_tbl_perm.id) table_id ,trim(pg_database.datname) db_name ,trim(pg_namespace.nspname) schema_name ,trim(pg_class.relname) tabl
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
ownCloudのパフォーマンスチューニング
前回、簡単に設定しましたが、パフォーマンスを考えると必要な設定がまだまだあります。パフォーマンスをよくするためのチューニングとしては、ownCloudでは以下のようなポイントがあります。 パフォーマンスチューニングのポイントは、いかにDiskへの書き込みを避け、メモリーを有効に活用するかにつきます。また、接続時のセッションを使い回し、PHPの中間コード生成回数を少なくし、DBの処理速度を上げることも行います。 それでは、チューニングポイントを以下の5つに分けて説明していきましょう。 cron設定 DBトランザクション分離レベルの変更とPHPのDB（mysqli）接続設定 PHPキャッシュの導入（OPcache、APCu） KVSの導入（Redis） Apache＋PHP-FPMの設定 cron設定 ownCloudにはJob実行機能があります。これは1時間に1回送信されるメール通知に利用さ
redisでaof,saveを有効化している場合にdiskを使い切るとどうなるか - teketeke_55の日記
redisはオンメモリで動くがファイルに書き込む設定をいれることで永続性を保つことができる。 そのファイルが書き込めなくなるとどうなるか調べてみた。 redisサーバ情報 amazon linux 3.4.37-40.44.amzn1.x86_64 redis 2.6.10 master slaveの2台構成 以下の設定でそれぞれ調査 #定期dump有効化 save 300 1#aof出力有効化 appendonly yes appendfsync everysec適当にddでtestファイルを使ってdisk容量を増やしておく $ df -h Filesystem Size Used Avail Use% マウント位置 /dev/xvda1 7.9G 7.8G 5.2M 100% / tmpfs 298M 0 298M 0% /dev/shmそしてredisにひたすらセットするだけのスクリ
ISUCON予選にPHP実装で参加して3位になりましたーやったことなどまとめ
by @dekokun on 2013/10/06 20:15 Tagged as: contest. 今日(10/6)はISUCON3の予選2日目に参加しました。 「予選落ちだろうなー」と思いながら挑んだら、意外と3位(暫定。運営の方が提出したAMIを起動しベンチマーク実行し、提出したスコアと比べてあまりにもスコアが低かった場合は失格となる)で本選進出が決まったので嬉しくてブログ書いてます。 スコアは14379で、予選1日目と合わせて9位。 「チームたこやき」という名前で後輩2人と参加しました。 題名に「PHP実装で」と入れたのは、ディスられがちなPHP書きへのエールを込めてです。 基本的にやってたこと 以下、恒常的にやってたこと一覧と、その効果を。 xhprofでのプロファイリング 効果：圧倒的 facebook謹製プロファイリングツール、xhprof様でございます session_s
実行計画の確認方法
実行計画は主に以下のような方法で取得することができます。本ページではそれぞれの設定手順を記載します。 ・sqlplusでauto traceを設定する ・SQLトレースを設定する ・explain plan文を実行する ・動的パフォーマンスビューから確認する(9i～) ・statistics_level=all＋dbms_xplan.display_cursorで実行計画＋行ソースレベルのSQL統計を確認する(9i～) 実行計画とは 実行計画とは指示されたSQLを処理するにあたっての内部的な方法や順番です。 どのような実行計画が立てられたとしても最終的な結果は全て同じになりますがパフォーマンスは実行計画によって大きく変化する場合があります。 実行計画はオプティマイザと呼ばれるエンジンが作成していますが、オプティマイザにはCBO(コストベースオプティマイザ)、RBO(ルールベースオプティマイ
MySQLのリアルタイムモニタリングに「innotop」
innotopとは 「innotop」はMySQLのクエリー実行状況やステータス変数の変化などをtopコマンド風に出力してくれる、Perlで書かれたスクリプトです。中身は非常にシンプル（SHOW GLOBAL STATUSやSHOW ENGINE INNODB STATUSなどをパースして表示するだけ）ですが、 topライクなインターフェイスはリアルタイムモニタリングと相性が良く、非常に直観的でわかりやすい情報を提供してくれます。 筆者はこれを「稼働中のサービスにALTER TABLE（またはpt-online-schema-change）をかける際の負荷モニター」や「MySQLが高負荷状態になっている時の状況確認」などによく利用しています。いかにもtopコマンドと同じような使い方です。 innotopの開発とメンテナンス innotopの立ち位置は少し微妙です。innotopはかつてPe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tuple vs List
PostgreSQL Performance Monitoring
embulk-filter-calcite vs embulk-filter-column|row の速度比較 - Qiita
Lessons learned from SQL Server process that took over 3000 hours
誰も教えてくれなかったMySQLの障害解析方法 - Qiita