Postgres2015全國使用者大會將於11月20至21日在北京麗亭華苑酒店召開。本次大會嘉賓陣容強大，國內頂級PostgreSQL資料庫專家將悉數到場，並特邀歐洲、俄羅斯、日本、美國等國家和地區的資料庫方面專家助陣:

• Postgres-XC專案的發起人鈴木市一(SUZUKI Koichi)
• Postgres-XL的專案發起人Mason Sharp
• pgpool的作者石井達夫(Tatsuo Ishii)
• PG-Strom的作者海外浩平(Kaigai Kohei)
• Greenplum研發總監姚延棟
• 周正中(德哥), PostgreSQL中國使用者會創始人之一
• 汪洋，平安科技資料庫技術部經理
• ……

2015年度PG大象會報名地址： http://postgres2015.eventdove.com/PostgreSQL中國社群： http://postgres.cn/PostgreSQL專業1群： 3336901（已滿）PostgreSQL專業2群： 100910388PostgreSQL專業3群： 150657323

在多核系統中，一般TPS會隨併發數的增加而提升，但是當併發數超過一定的數值（如CPU核數的2到3倍以後），效能開始下降，併發數越高，下降越嚴重。 例子： 更新500萬記錄表中的1條隨機記錄。開8000個併發。 create table test_8000 (id int primary key, cnt intdefault

0);insert into test_8000 select generate_series(1,5000000);vi t.sql\setrandom id 15000000update test_8000 set cnt=cnt+1where id=:id;update test_8000 set cnt=cnt+2where id=:id; 每次載入80個併發，迴圈100次，一共載入8000個併發。 vi test.sh#!/bin/bashfor ((i=0;i<100;i++))dosleep 1;pgbench -M simple -n -r -f ./t.sql -c 80-j 80-T 100000-U postgres &done 開始 .

./test.sh 當連線數達到8000後，觀察TPS，我們可以使用PG的統計資訊表來計算QPS。 postgres=# select count(*) from pg_stat_activity; count -------  8002(1 row)postgres=# select timestamptz '2015-10-08 17:01:24.203089+08' - timestamptz '2015-10-08 17:01:16.574076+08';    ?column?     ----------------- 00:00:07.629013(1 row)postgres=# select 43819090-43749480; ?column? ----------    69610(1 row)postgres=# select 69610/07.629013;       ?column?        ----------------------- 9124.3782124896103860(1 row) 8000個併發的時候，更新TPS約9124。大部分時間可能浪費在CPU排程上了。 另一種場景， 如果有8000個併發是空閒連線，只有10個在執行更新，效能是這樣的： 先製造8000個空閒連線： vi test.sqlselect pg_sleep(100000);vi test.sh#!/bin/bashfor ((i=0;i<100;i++))dosleep 1;pgbench -M simple -n -r -f ./test.sql -c 80-j 80-T 100000-U postgres &done../test.shpostgres=# select count(*) from pg_stat_activity; count -------  8002(1 row) 然後開啟10個連線執行更新操作。 pgbench -M prepared -n -r -f ./t.sql -P 1-c 10-j 10-T 1000-U postgres postgresprogress:1.0 s,29429.2 tps, lat 0.336 ms stddev 0.109progress:2.0 s,28961.1 tps, lat 0.343 ms stddev 0.114progress:3.0 s,30433.8 tps, lat 0.326 ms stddev 0.103progress:4.0 s,29597.1 tps, lat 0.336 ms stddev 0.114progress:5.0 s,28714.1 tps, lat 0.346 ms stddev 0.117progress:6.0 s,28319.0 tps, lat 0.351 ms stddev 0.121progress:7.0 s,28540.0 tps, lat 0.348 ms stddev 0.118progress:8.0 s,29408.9 tps, lat 0.338 ms stddev 0.111progress:9.0 s,29178.1 tps, lat 0.340 ms stddev 0.119progress:10.0 s,29146.9 tps, lat 0.341 ms stddev 0.118progress:11.0 s,27498.5 tps, lat 0.361 ms stddev 0.123 這種方法的效能約6萬 qps。 優化思路： 排隊處理使用者請求。類似pgbouncer或Oracle的shared server機制，真實處理請求的程序數有限。 使用PostgreSQL的advisory函式可以模擬這種排隊機制： create or replace function upd(l int,v_id int) returns voidas $$declarebegin  LOOPif pg_try_advisory_xact_lock(l)then--只有獲得這個應用級鎖才執行更新，否則就等待。      update test_8000 set cnt=cnt+1where id=v_id;      update test_8000 set cnt=cnt+2where id=v_id;return;else      perform pg_sleep(30*random());--隨機等待時間endif;END LOOP;end;$$ language plpgsql strict; 增加一個隨機變數l，用來表示應用所的號碼，也就是說模擬10個同時在更新的操作，其他的都在等待。 這個是沒有經過優化的排隊機制，因為不是獨立的程序處理使用者請求，依舊是backend process在處理使用者請求，依舊有8000個程序。 vi t.sql\setrandom id 15000000\setrandom l 110select upd(:l,:id);vi test.sh#!/bin/bashfor ((i=0;i<100;i++))dosleep 1;pgbench -M simple -n -r -f ./t.sql -c 80-j 80-T 100000-U postgres &done../test.sh 測試結果比較理想，已經提升了1倍效能。 postgres=# select now(),n_tup_upd+n_tup_hot_upd from pg_stat_all_tables where relname='test_8000';
now |?column?
-------------------------------+-----------
2015-10-0819:06:37.951332+08|221045069
(1 row)postgres=# select now(),n_tup_upd+n_tup_hot_upd from pg_stat_all_tables where relname='test_8000';
now |?column?
------------------------------+-----------
2015-10-0819:07:46.46325+08|222879057

相關推薦

PostgreSQL資料庫 OLTP高併發請求效能優化

Postgres2015全國使用者大會將於11月20至21日在北京麗亭華苑酒店召開。本次大會嘉賓陣容強大，國內頂級PostgreSQL資料庫專家將悉數到場，並特邀歐洲、俄羅斯、日本、美國等國家和地區的資料庫方面專家助陣: Postgres-XC專案的發起人鈴木市一

HttpClient高併發下效能優化-http連線池

首先,明確兩點: 1.http連線池不是萬能的,過多的長連線會佔用伺服器資源,導致其他服務受阻 2.http連線池只適用於請求是經常訪問同一主機(或同一個介面)的情況下 3.併發數不高的情況下資源利用率低下 那麼,當你的業務符合上面3點,那麼你可以考慮使用http連線池來提高伺服器效能

大型網際網路公司必備的架構技術棧——分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰

效能優化 JVM調優 Java程式效能優化 Tomcat Mysql Spring IOC Spring AOP Spring MVC Spring 5新特性 Mybatis 分散式架構 架構核心服務層技術 架構關鍵技術設施 分散式訊息通訊 非同

Java高架構師、分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師之路

工作1-5年開發經驗，當你們提出漲工資的時候，或者要offer的時候底氣怎麼樣，是不是底氣十足，不給漲工資就辭職，是不是有自信提出來主管、或者是專案經理都能同意，他們相當設法把你留住。如果這樣你才是成功。什麼技術都沒有何談工資！ 給你分析一下這些技術，給大家羅列一些技術，看

高併發&效能優化（一）------總體介紹

【開篇詞】 本文主要通過一些經典的高併發場景，以及一些基本的運維工具來講述一些關於高併發以及效能優化相關的內容，主要包括效能瓶頸的定位，效能調優的思路和技巧等。     【效能的衡量指標】 ？什麼是效能 效能就是，在有限的時間內，使用有限的資源，完成任務。 在儲存資源成本越來越低

高併發&效能優化（二）------系統監控工具使用

上一篇主要從總體介紹了高併發&效能優化的相關思路和方法，本篇主要介紹系統監控工具。     【CPU檢視工具】 ------top命令（效能） 進入top命令後，按1即可看到每核CPU的執行指標與詳細指標： 咱們依次說明下紅框裡面的引數： Load Average

Java高併發(五)——Lock優化，提高效能

       前邊我們講了，多執行緒的世界，多執行緒的基礎操作，多執行緒協作，多執行緒管理——執行緒池。其中多執行緒為什麼麻煩，就因為執行緒並行操作，對共享資源的爭奪，會出現執行緒安全問題。而我們解決執行緒安全問題的方案是同步（鎖資源，序列使用），序列就會出現

模擬高併發請求服務端（python gevent）

專案背景：對web後端進行高併發的請求，簡單測試服務框架的效能 解決思路：利用python的多執行緒，但python的多執行緒有點“雞肋”， 個人選擇使用簡潔輕便gevent。 解決方案：採用gevent非同步 + requests 進行高併發請求 import time import

Web大規模高併發請求和搶購的原理及解決方案

電商的秒殺和搶購，對我們來說，都不是一個陌生的東西。然而，從技術的角度來說，這對於Web系統是一個巨大的考驗。當一個Web系統，在一秒鐘內收到數以萬計甚至更多請求時，系統的優化和穩定至關重要。這次我們會關注秒殺和搶購的技術實現和優化，同時，從技術層面揭開，為什麼我們總是不容易搶到火車票的原因？&nb

Web大規模高併發請求和搶購的解決方案

電商的秒殺和搶購，對我們來說，都不是一個陌生的東西。然而，從技術的角度來說，這對於Web系統是一個巨大的考驗。當一個Web系統，在一秒鐘內收到數以萬計甚至更多請求時，系統的優化和穩定至關重要。這次我們會關注秒殺和搶購的技術實現和優化，同時，從技術層面揭開，為什麼我們總是不容易搶到火車票的原因

資料庫大批量SQL插入效能優化

對於一些資料量較大的系統，資料庫面臨的問題除了查詢效率低下，還有就是資料入庫時間長。特別像報表系統，每天花費在資料匯入上的時間可能會長達幾個小時或十幾個小時之久。因此，優化資料庫插入效能是很有意義的。 經過對MySQL InnoDB的一些效能測試，發現一些可以提高ins

springcloud非同步執行緒池、高併發請求feign解決方案

ScenTaskTestApplication.java package com.test; import org.springframework.boot.SpringApplication; import org.springframework.boot.a

大資料量高併發訪問SQL優化方法

保證在實現功能的基礎上，儘量減少對資料庫的訪問次數；通過搜尋引數，儘量減少對錶的訪問行數,最小化結果集，從而減輕網路負擔；能夠分開的操作儘量分開處理，提高每次的響應速度；在資料視窗使用SQL時，儘量把使用的索引放在選擇的首列；演算法的結構儘量簡單；在查詢時，不要過多地使用萬用

《連載 | 物聯網框架ServerSuperIO教程》- 17.整合Golden實時資料庫，高併發儲存測點資料。附：3.4 釋出與版本更新說明。

目       錄 17．支援實時資料庫，高併發儲存測點資料... 2 17.1        概述... 2 17.2        ServerSuperIO與實時資料庫對接... 4 17.2.1       繼承動態介面，

達達O2O後臺架構演進實踐：從0到4000高併發請求背後的努力

1、引言 達達創立於2014年5月，業務覆蓋全國37個城市，擁有130萬註冊眾包配送員，日均配送百萬單，是全國領先的最後三公里物流配送平臺。 達達的業務模式與滴滴以及Uber很相似，以眾包的方式利用社會閒散人力資源，解決O2O最後三公里即時性配送難題（2016年4月，達達已經與京東到家合併

執行緒池處理高併發請求

背景 本系統（支付系統）會在每個月特定時間（如賬單日某個時間）接收上游系統發起的大量請求並進行處理，並在處理完成後返回結果給上游系統。而本系統接收到請求進行處理的過程是呼叫第三方（支付公司）進行處理並獲取結果。 系統原實現方案沒有采用任何控制請求併發數的措施，接

資料庫 之 高併發環境下的規則

原文: 資料庫 之 高併發環境下的規則 本文大部分轉至沈劍老師，加上自己的一些見解。   本文前提 高併發環境   規則要點 1） 資料庫字符集使用utf8mb4 無亂碼風險、萬國碼 2）禁止使用儲存過程、檢視、觸發器、Event 高併發大資料的網際網路業務，架構設計思

nginx工作原理和實現高併發請求的原因

一、程序、執行緒？程序是具有一定獨立功能的，在計算機中已經執行的程式的實體。在早期系統中（如linux 2.4以前），程序是基本運作單位，在支援執行緒的系統中（如windows，linux2.6）中，執行緒才是基本的運作單位，而程序只是執行緒的容器。程式 本身只是指令、資料及

PHP中利用redis實現訊息佇列處理高併發請求

將請求存入redis 為了模擬多個使用者的請求,使用一個for迴圈替代 //redis資料入隊操作 $redis = new Redis(); $redis->connect('127.0.0.1',6379); for($i=0;$i<50;$i++){

mysql 資料庫處理高併發、 大資料量 .日常軍規

?6?1 來自一線的實戰經驗?6?1 每一軍規背後都是血淋淋教訓?6?1 丌要華麗，叧要實用?6?1 若有一條讓你有所受益，慰矣?6?1 主要針對資料庫開發人員總是在災難發生後，才想起容災的重要性；總是在吃過虧後，才記得曾經有人提醒過。目錄一.核心軍規(5)二.欄位類軍規(6)三.索引類軍規(5)四.SQL類