押さえておきたい、PostgreSQL 13 の新機能!!(Open Source Conference 2021 Online/Hokkaido 発表資料)
![まずやっとくPostgreSQLチューニング](https://cdn-ak-scissors.b.st-hatena.com/image/square/85b5d3a6b9021b84dd3e7ea23d9bfb1fe108b515/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fpostgresqlslideshare-140720150932-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
サービスを初めてから高負荷になるまで さて、今回からは具体的に、個人でサービスを初めてからシステムを増強していくまでの課程を説明していきたいと思います。 まずサービスを始める際は、手っ取り早さやコストの問題などから、複数のユーザと共有のレンタルサーバから始めるケースが多いですが、ある程度の人気が出てくるとアクセスに耐えきれなくなり専用サーバを借りるというパターンになると思います。 ここまではわかりやすくシステムを増強することができるのですが、専用サーバで耐えきれなくなってきた際はそれ以降はどのようにすればよいのでしょうか? その負荷はホンモノか? まず、サーバの負荷が高いといっても現象はさまざまです。負荷が高いといった現象は具体的に発見されるのは、「ユーザから見たレスポンス」から発見されることが多いはずです。 ここで単純に「サーバを増強しなければ!」と判断はせずに、何が原因でパフォーマン
「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネック 第2回、第3回ではディスクI/Oボトルネックについて説明しました。レスポンスとスループットの関係を正しく理解し、I/Oスループットを最大化するようチューニングすれば、ほとんどの大規模処理は速くなります。ユーザもハッピー、皆さんもハッピー、さて家に帰りましょう。 ……しかし、次はだれかからこう聞かれることでしょう。 「CPUの使用率が異様に低いままなんだけど……?」 「CPUの使用率がずっと100%で張り付いているんだけど……?」 どっちやねん!と思うでしょうが、どちらも大規模データを処理するときに特に起こりえる問題です。 ボトルネックは、1つが解消すると、新たなポイントが明らかになるものです。そして多くのケースにおいて、ディスクI/Oボトルネックが解消した場合、次に詰まるのはCPUなのです。 CPUボトルネックは
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか? そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
世の中に存在するシステムは、多かれ少なかれパフォーマンス上の問題を抱えています。問題の解決には、パフォーマンステストを適切に実施し、ボトルネックを浮き彫りにすることが有効です。本書は、精度の高いパフォーマンステストを求める人のための技術書です。パフォーマンステストの論理的根拠、効果的なテスト構成要素など基礎的なことから、パフォーマンステストのプロセス、結果の解釈、またトランザクション例など発展的な内容まで、パフォーマンステストを包括的に解説します。ミッションクリティカルなソフトウェア開発者、テスター、プロジェクトマネージャ必読の一冊です。 訳者まえがき はじめに 1章 なぜパフォーマンステストをするのか? 1.1 パフォーマンステストとはなにか:エンドユーザの視点 1.1.1 パフォーマンス計測 1.1.2 パフォーマンス標準 1.1.3 インターネット効果 1.2 劣悪なパフォーマンス:
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ&コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。(何でもそうですけど)インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
ニコニコ超会議で開催された「超チューニング祭り」に恋人である武藤スナイパーカスタムからお誘いされて参加しました。 投票してくださった方々のおかげで最優秀賞! ありがとうございます! ニコ動モバイル版のトップページのhtml,css,jsを軽量化するお祭りでして、にぎやかな会場、狭いブースの中で詰め込まれておもしろかったです。 チーム:ウルフギャングの紹介 エンジニア、デザイナーのバランスチーム。 武藤さんが狼が好きなのでそれっぽい名前にしました。ギャングらしくふたりとも革ジャン装備。 武藤スナイパーカスタム Twitter : tai2 コンピューターグラフィックスとPythonをこよなく愛すマッチ棒エンジニア。 イシジマミキ Twitter : woopsdez 写真をアップするたびにおおつねさんに「太った?」と言われる番付上昇中のデザイナー 他はエンジニアふたり、個人での参加などが
日本アニメ初の快挙!海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
自分の書いたコードが即座に解析できる「StyleStats」でCSSを測ろう! 石本 光司(Kaizen Platform, Inc...) こんにちわ、@t32kだよ! 私は仕事では主にHTML/CSSコーディングを担当しているのですが、自分の書いたCSSがイケてるのか、そうでないのか、気になります。私、気になります!そうでなくても、他プロジェクトのCSSのレビューをお願いされたりすることもあるので、そのCSSがどのような状態であるのか、すばやく簡単に理解する必要性がありました。 そこで私は、StyleStatsというNode.js製のツールを作りました。 t32k/stylestats – GitHub StyleStatsの使い方はとても簡単です。ターミナルから下記コマンドを打てば、すぐにCSSを解析した結果が得られます。 $ npm install -g stylestats $
Webサービスを開発/運用してるモンとしては、いろんなWebサービスを触ってみなきゃアカンってことで、アメリカの若モンに大人気ってふれこみのsnapchatに登録してみた。これでリア充の仲間入りやと思ったが、snapchat友達が同僚二人しかいないうえに、利用シーンがあまり思い浮かばないww オジサン困っちゃいました。画像とか送信できるんだけど、数秒で消えるの。むしろそこがウリっていうね。どうやって遊ぼうか…。 2月はブログ書かなかったなーと思ったのでMySQL小ネタ。世間的にも自分的にも真新しくもなんともないTipsです。 innotopで集計 実は以前、Qiitaに書いたので↓をば。。。 http://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa 流れるクエリ、ロックの状況、トランザクション(show engine innodb s
「HTML5 Advent Calendar 2013」の24日目の記事です。 Webアプリのパフォーマンス改善と言えば、JavaScriptやDOMアクセスなど、既存の技術ベースな改善手法を想像する方も多いでしょう。最近では、こうした改善のあり方を、別の視点からもう少し広げようというアイデアが存在感を持ち始めています。それは「Web標準」です。 そこで今回、Web標準側でできるWebアプリのパフォーマンス改善について、掻い摘んで紹介します。全てを説明となるとキリがないので、キーワードを中心とさせて頂きます。最近になって、結構実用化が進んできているので、悩んだ時には試してみる価値はあるでしょう。 1. リソースを先に読み込む linkタグにてURLなどを指定することで、これから先に読み込ませる可能性が高いWebページのリソースを予め読み込むWeb標準があります。ニュースサイトでは次のページ
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ!この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. \こんにちは!/ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日本 MySQL ユーザ会 (MyNA) のスベり担当 3. \しゃべること!/ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・ テーブル構築・運営、 DBA はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く