亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

:MapReduce: 提高M(jìn)apReduce性能的七點(diǎn)建議[譯]

系統(tǒng) 2747 0

轉(zhuǎn)載自: 每天一小步

??????? Cloudera提供給客戶的服務(wù)內(nèi)容之一就是調(diào)整和優(yōu)化MapReduce job執(zhí)行性能。MapReduce和HDFS組成一個(gè)復(fù)雜的分布式系統(tǒng),并且它們運(yùn)行著各式各樣用戶的代碼,這樣導(dǎo)致沒(méi)有一個(gè)快速有效的規(guī)則來(lái)實(shí)現(xiàn)優(yōu)化 代碼性能的目的。在我看來(lái),調(diào)整cluster或job的運(yùn)行更像一個(gè)醫(yī)生對(duì)待病人一樣,找出關(guān)鍵的“癥狀”,對(duì)于不同的癥狀有不同的診斷和處理方式。

??????? 在醫(yī)學(xué)領(lǐng)域,沒(méi)有什么可以代替一位經(jīng)驗(yàn)豐富的醫(yī)生;在復(fù)雜的分布式系統(tǒng)上,這個(gè)道理依然正確—有經(jīng)驗(yàn)的用戶和操作者在面對(duì)很多常見(jiàn)問(wèn)題上都會(huì)有“第六 感”。我曾經(jīng)為Cloudera不同行業(yè)的客戶解決過(guò)問(wèn)題,他們面對(duì)的工作量、數(shù)據(jù)集和cluster硬件有很大區(qū)別,因此我在這方面積累了很多的經(jīng)驗(yàn), 并且想把這些經(jīng)驗(yàn)分享給諸位。

??????? 在這篇blog里,我會(huì)高亮那些提高M(jìn)apReduce性能的建議。前面的一些建議是面向整個(gè)cluster的,這可能會(huì)對(duì)cluster 操作者和開(kāi)發(fā)者有幫助。后面一部分建議是為那些用Java編寫(xiě)MapReduce job的開(kāi)發(fā)者而提出。在每一個(gè)建議中,我列出一些“癥狀”或是“診斷測(cè)試”來(lái)說(shuō)明一些針對(duì)這些問(wèn)題的改進(jìn)措施,可能會(huì)對(duì)你有所幫助。

??????? 請(qǐng)注意,這些建議中包含很多我以往從各種不同場(chǎng)景下總結(jié)出來(lái)的直觀經(jīng)驗(yàn)。它們可能不太適用于你所面對(duì)的特殊的工作量、數(shù)據(jù)集或cluster,如果你想使 用它,就需要測(cè)試使用前和使用后它在你的cluster環(huán)境中的表現(xiàn)。對(duì)于這些建議,我會(huì)展示一些對(duì)比性的數(shù)據(jù),數(shù)據(jù)產(chǎn)生的環(huán)境是一個(gè)4個(gè)節(jié)點(diǎn)的 cluster來(lái)運(yùn)行40GB的Wordcount job。應(yīng)用了我以下所提到的這些建議后,這個(gè)job中的每個(gè)map task大概運(yùn)行33秒,job總共執(zhí)行了差不多8分30秒。

第一點(diǎn)? 正確地配置你的Cluster
診斷結(jié)果/癥狀:
1. Linux top命令的結(jié)果顯示slave節(jié)點(diǎn)在所有map和reduce slot都有task運(yùn)行時(shí)依然很空閑。
2. top命令顯示內(nèi)核的進(jìn)程,如RAID(mdX_raid*)或pdflush占去大量的CPU時(shí)間。
3. Linux的平均負(fù)載通常是系統(tǒng)CPU數(shù)量的2倍。
4. 即使系統(tǒng)正在運(yùn)行job,Linux平均負(fù)載總是保持在系統(tǒng)CPU數(shù)量的一半的狀態(tài)。
5. 一些節(jié)點(diǎn)上的swap利用率超過(guò)幾MB

??? 優(yōu)化你的MapReduce性能的第一步是確保你整個(gè)cluster的配置文件被調(diào)整過(guò)。對(duì)于新手,請(qǐng)參考這里關(guān)于配置參數(shù)的一篇blog: 配置參數(shù) 。 除了這些配置參數(shù) ,在你想修改job參數(shù)以期提高性能時(shí),你應(yīng)該參照下我這里的一些你應(yīng)該注意的項(xiàng):

1.? 確保你正在DFS和MapReduce中使用的存儲(chǔ)mount被設(shè)置了noatime選項(xiàng)。這項(xiàng)如果設(shè)置就不會(huì)啟動(dòng)對(duì)磁盤(pán)訪問(wèn)時(shí)間的記錄,會(huì)顯著提高IO的性能。

2. 避免在TaskTracker和DataNode的機(jī)器上執(zhí)行RAID和LVM操作,這通常會(huì)降低性能

3. 在這兩個(gè)參數(shù) mapred.local.dir dfs.data.dir 配置的值應(yīng)當(dāng)是分布在各個(gè)磁盤(pán)上目錄,這樣可以充分利用節(jié)點(diǎn)的IO讀寫(xiě)能力。運(yùn)行 Linux sysstat包下的 iostat -dx 5 命令可以讓每個(gè)磁盤(pán)都顯示它的利用率。

4. 你應(yīng)該有一個(gè)聰明的監(jiān)控系統(tǒng)來(lái)監(jiān)控磁盤(pán)設(shè)備的健康狀態(tài)。MapReduce job的設(shè)計(jì)是可容忍磁盤(pán)失敗,但磁盤(pán)的異常會(huì)導(dǎo)致一些task重復(fù)執(zhí)行而使性能下降。如果你發(fā)現(xiàn)在某個(gè)TaskTracker被很多job中列入黑名單,那么它就可能有問(wèn)題。

5. 使用像Ganglia這樣的工具監(jiān)控并繪出swap和網(wǎng)絡(luò)的利用率圖。如果你從監(jiān)控的圖看出機(jī)器正在使用swap內(nèi)存,那么減少 mapred.child.java.opts 屬性所表示的內(nèi)存分配。

基準(zhǔn)測(cè)試:
??? 很遺憾我不能為這個(gè)建議去生成一些測(cè)試數(shù)據(jù),因?yàn)檫@需要構(gòu)建整個(gè)cluster。如果你有相關(guān)的經(jīng)驗(yàn),請(qǐng)把你的建議及結(jié)果附到下面的留言區(qū)。

第二點(diǎn)? 使用LZO壓縮
診斷結(jié)果/癥狀:
1. 對(duì) job的中間結(jié)果數(shù)據(jù)使用壓縮是很好的想法。
2. MapReduce job的輸出數(shù)據(jù)大小是不可忽略的。
3. 在job運(yùn)行時(shí),通過(guò)linux top 和 iostat命令可以看出slave節(jié)點(diǎn)的iowait利用率很高。

??? 幾乎每個(gè)Hadoop job都可以通過(guò)對(duì)map task輸出的中間數(shù)據(jù)做LZO壓縮獲得較好的空間效益。盡管LZO壓縮會(huì)增加一些CPU的負(fù)載,但在shuffle過(guò)程中會(huì)減少磁盤(pán)IO的數(shù)據(jù)量,總體上總是可以節(jié)省時(shí)間的。

??? 當(dāng)一個(gè)job需要輸出大量數(shù)據(jù)時(shí),應(yīng)用LZO壓縮可以提高輸出端的輸出性能。這是因?yàn)槟J(rèn)情況下每個(gè)文件的輸出都會(huì)保存3個(gè)幅本,1GB的輸出文件你將要保存3GB的磁盤(pán)數(shù)據(jù),當(dāng)采用壓縮后當(dāng)然更能節(jié)省空間并提高性能。

??? 為了使LZO壓縮有效,請(qǐng)?jiān)O(shè)置參數(shù) mapred.compress.map.output 值為true。

基準(zhǔn)測(cè)試:
??? 在我的cluster里,Wordcount例子中不使用LZO壓縮的話,job的運(yùn)行時(shí)間只是稍微增加。但FILE_BYTES_WRITTEN計(jì)數(shù)器 卻從3.5GB增長(zhǎng)到9.2GB,這表示壓縮會(huì)減少62%的磁盤(pán)IO。在我的cluster里,每個(gè)數(shù)據(jù)節(jié)點(diǎn)上磁盤(pán)數(shù)量對(duì)task數(shù)量的比例很高,但 Wordcount job并沒(méi)有在整個(gè)cluster中共享,所以cluster中IO不是瓶頸,磁盤(pán)IO增長(zhǎng)不會(huì)有什么大的問(wèn)題。但對(duì)于磁盤(pán)因很多并發(fā)活動(dòng)而受限的環(huán)境來(lái) 說(shuō),磁盤(pán)IO減少60%可以大幅提高job的執(zhí)行速度。

第三點(diǎn)? 調(diào)整map和reduce task的數(shù)量到合適的值
診斷結(jié)果/癥狀:
1. 每個(gè)map或reduce task的完成時(shí)間少于30到40秒。
2. 大型的job不能完全利用cluster中所有空閑的slot。
3. 大多數(shù)map或reduce task被調(diào)度執(zhí)行了,但有一到兩個(gè)task還在準(zhǔn)備狀態(tài),在其它task完成之后才單獨(dú)執(zhí)行

??? 調(diào)整job中map和reduce task的數(shù)量是一件很重要且常常被忽略的事情。下面是我在設(shè)置這些參數(shù)時(shí)的一些直觀經(jīng)驗(yàn):

1. 如果每個(gè)task的執(zhí)行時(shí)間少于30到40秒,就減少task的數(shù)量。Task的創(chuàng)建與調(diào)度一般耗費(fèi)幾秒的時(shí)間,如果task完成的很快,我們就是在浪費(fèi)時(shí)間。同時(shí),設(shè)置JVM重用也可以解決這個(gè)問(wèn)題。

2. 如果一個(gè)job的輸入數(shù)據(jù)大于1TB,我們就增加block size到256或者512,這樣可以減少task的數(shù)量。你可以使用這個(gè)命令去修改已存在文件的block size: hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata? /path/to/inputdata-with/largeblocks 。在執(zhí)行完這個(gè)命令后,你就可以刪除原始的輸入文件了(/path/to/inputdata)。

3. 只要每個(gè)task運(yùn)行至少30到40秒,那么就增加map task的數(shù)量,增加到整個(gè)cluster上map slot總數(shù)的幾倍。如果你的cluster中有100個(gè)map slot,那就避免運(yùn)行一個(gè)有101個(gè)map task的job — 如果運(yùn)行的話,前100個(gè)map同時(shí)執(zhí)行,第101個(gè)task會(huì)在reduce執(zhí)行之前單獨(dú)運(yùn)行。這個(gè)建議對(duì)于小型cluste和小型job是很重要的。

4. 不要調(diào)度太多的reduce task — 對(duì)于大多數(shù)job來(lái)說(shuō),我們推薦reduce task的數(shù)量應(yīng)當(dāng)?shù)扔诨蚴锹孕∮赾luster中reduce slot的數(shù)量。

基準(zhǔn)測(cè)試:
??? 為了讓W(xué)ordcount job有很多的task運(yùn)行,我設(shè)置了如下的參數(shù): Dmapred.max.split.size=$[16*1024*1024] 。 以前默認(rèn)會(huì)產(chǎn)生360個(gè)map task,現(xiàn)在就會(huì)有2640個(gè)。當(dāng)完成這個(gè)設(shè)置之后,每個(gè)task執(zhí)行耗費(fèi)9秒,并且在JobTracker的Cluster Summar視圖中可以觀看到,正在運(yùn)行的map task數(shù)量在0到24之間浮動(dòng)。job在17分52秒之后結(jié)束,比原來(lái)的執(zhí)行要慢兩倍多。

第四點(diǎn)? 為job添加一個(gè)Combiner
診斷結(jié)果/癥狀:
1. job在執(zhí)行分類的聚合時(shí),REDUCE_INPUT_GROUPS計(jì)數(shù)器遠(yuǎn)小于REDUCE_INPUT_RECORDS計(jì)數(shù)器。
2. job執(zhí)行一個(gè)大的shuffle任務(wù)(例如,map的輸出數(shù)據(jù)每個(gè)節(jié)點(diǎn)就是好幾個(gè)GB)。
3. 從job計(jì)數(shù)器中看出,SPILLED_RECORDS遠(yuǎn)大于MAP_OUTPUT_RECORDS。

??? 如果你的算法涉及到一些分類的聚合,那么你就可以使用Combiner來(lái)完成數(shù)據(jù)到達(dá)reduce端之前的初始聚合工作。MapReduce框架很明智地運(yùn)用Combiner來(lái)減少寫(xiě)入磁盤(pán)以及通過(guò)網(wǎng)絡(luò)傳輸?shù)絩educe端的數(shù)據(jù)量。

基準(zhǔn)測(cè)試:
??? 我刪去Wordcount例子中對(duì)setCombinerClass方法的調(diào)用。僅這個(gè)修改就讓map task的平均運(yùn)行時(shí)間由33秒增長(zhǎng)到48秒,shuffle的數(shù)據(jù)量也從1GB提高到1.4GB。整個(gè)job的運(yùn)行時(shí)間由原來(lái)的8分30秒變成15分 42秒,差不多慢了兩倍。這次測(cè)試過(guò)程中開(kāi)啟了map輸出結(jié)果的壓縮功能,如果沒(méi)有開(kāi)啟這個(gè)壓縮功能的話,那么Combiner的影響就會(huì)變得更加明顯。

第五點(diǎn)? 為你的數(shù)據(jù)使用最合適和簡(jiǎn)潔的Writable類型
診斷/癥狀:
1. Text 對(duì)象在非文本或混合數(shù)據(jù)中使用。
2. 大部分的輸出值很小的時(shí)候使用IntWritable 或 LongWritable對(duì)象。

??? 當(dāng)一個(gè)開(kāi)發(fā)者是初次編寫(xiě)MapReduce,或是從開(kāi)發(fā)Hadoop Streaming轉(zhuǎn)到Java MapReduce,他們會(huì)經(jīng)常在不必要的時(shí)候使用Text 對(duì)象。盡管Text對(duì)象使用起來(lái)很方便,但它在由數(shù)值轉(zhuǎn)換到文本或是由UTF8字符串轉(zhuǎn)換到文本時(shí)都是低效的,且會(huì)消耗大量的CPU時(shí)間。當(dāng)處理那些非文 本的數(shù)據(jù)時(shí),可以使用二進(jìn)制的Writable類型,如IntWritable, FloatWritable等。

??? 除了避免文件轉(zhuǎn)換的消耗外,二進(jìn)制Writable類型作為中間結(jié)果時(shí)會(huì)占用更少的空間。當(dāng)磁盤(pán)IO和網(wǎng)絡(luò)傳輸成為大型job所遇到的瓶頸時(shí),減少些中間 結(jié)果的大小可以獲得更好的性能。在處理整形數(shù)值時(shí),有時(shí)使用VIntWritable或VLongWritable類型可能會(huì)更快些—這些實(shí)現(xiàn)了變長(zhǎng)整形 編碼的類型在序列化小數(shù)值時(shí)會(huì)更節(jié)省空間。例如,整數(shù)4會(huì)被序列化成單字節(jié),而整數(shù)10000會(huì)被序列化成兩個(gè)字節(jié)。這些變長(zhǎng)類型用在統(tǒng)計(jì)等任務(wù)時(shí)更加有 效,在這些任務(wù)中我們只要確保大部分的記錄都是一個(gè)很小的值,這樣值就可以匹配一或兩個(gè)字節(jié)。

??? 如果Hadoop自帶的Writable類型不能滿足你的需求,你可以開(kāi)發(fā)自己的Writable類型。這應(yīng)該是挺簡(jiǎn)單的,可能會(huì)在處理文本方面更快些。 如果你編寫(xiě)了自己的Writable類型,請(qǐng)務(wù)必提供一個(gè)RawComparator類—你可以以內(nèi)置的Writable類型做為例子。

基準(zhǔn)測(cè)試:
??? 對(duì)于Wordcount例子,我修改了它在map計(jì)數(shù)時(shí)的中間變量,由IntWritable改為T(mén)ext。并且在reduce統(tǒng)計(jì)最終和時(shí)使用 Integer.parseString(value.toString)來(lái)轉(zhuǎn)換出真正的數(shù)值。這個(gè)版本比原始版本要慢近10%—整個(gè)job完成差不多超 過(guò)9分鐘,且每個(gè)map task要運(yùn)行36秒,比之前的33秒要慢。盡量看起來(lái)整形轉(zhuǎn)換還是挺快的,但這不說(shuō)明什么情況。在正常情況下,我曾經(jīng)看到過(guò)選用合適的Writable 類型可以有2到3倍的性能提升的例子。

第六點(diǎn)? 重用Writable類型
診斷/癥狀:
1. 在mapred.child.java.opts參數(shù)上增加-verbose:gc -XX:+PriintGCDetails,然后查看一些task的日志。如果垃圾回收頻繁工作且消耗一些時(shí)間,你需要注意那些無(wú)用的對(duì)象。
2. 在你的代碼中搜索"new Text" 或"new IntWritable"。如果它們出現(xiàn)在一個(gè)內(nèi)部循環(huán)或是map/reduce方法的內(nèi)部時(shí),這條建議可能會(huì)很有用。
3. 這條建議在task內(nèi)存受限的情況下特別有用。

??? 很多MapReduce用戶常犯的一個(gè)錯(cuò)誤是,在一個(gè)map/reduce方法中為每個(gè)輸出都創(chuàng)建Writable對(duì)象。例如,你的Wordcout mapper方法可能這樣寫(xiě):

Java代碼 ? 收藏代碼
  1. public ? void ?map(...)?{??
  2. ??????…??
  3. ?????? for ?(String?word?:?words)?{??
  4. ??????????????output.collect( new ?Text(word),? new ?IntWritable( 1 ));??
  5. ??????}??
  6. }??



??? 這樣會(huì)導(dǎo)致程序分配出成千上萬(wàn)個(gè)短周期的對(duì)象。Java垃圾收集器就要為此做很多的工作。更有效的寫(xiě)法是:

Java代碼 ? 收藏代碼
  1. class ?MyMapper?…?{??
  2. ???Text?wordText?=? new ?Text();??
  3. ???IntWritable?one?=? new ?IntWritable( 1 );??
  4. ??? public ? void ?map(...)?{??
  5. ????????? for ?(String?word:?words)?{??
  6. ???????????????wordText.set(word);??
  7. ???????????????output.collect(wordText,?one);??
  8. ??????????}??
  9. ???????}??
  10. }??


基準(zhǔn)測(cè)試:
??? 當(dāng)我以上面的描述修改了Wordcount例子后,起初我發(fā)現(xiàn)job運(yùn)行時(shí)與修改之前沒(méi)有任何不同。這是因?yàn)樵谖业腸luster中默認(rèn)為每個(gè)task都 分配一個(gè)1GB的堆大小 ,所以垃圾回收機(jī)制沒(méi)有啟動(dòng)。當(dāng)我重新設(shè)置參數(shù),為每個(gè)task只分配200MB的堆時(shí),沒(méi)有重用Writable對(duì)象的這個(gè)版本執(zhí)行出現(xiàn)了很?chē)?yán)重的減緩 —job的執(zhí)行時(shí)間由以前的大概8分30秒變成現(xiàn)在的超過(guò)17分鐘。原始的那個(gè)重用Writable的版本,在設(shè)置更小的堆時(shí)還是保持相同的執(zhí)行速度。因 此重用Writable是一個(gè)很簡(jiǎn)單的問(wèn)題修正,我推薦大家總是這樣做。它可能不會(huì)在每個(gè)job的執(zhí)行中獲得很好的性能,但當(dāng)你的task有內(nèi)存限制時(shí)就 會(huì)有相當(dāng)大的區(qū)別。

第七點(diǎn)? 使用簡(jiǎn)易的剖析方式查看task的運(yùn)行
??? 這是我在查看MapReduce job性能問(wèn)題時(shí)常用的一個(gè)小技巧。那些不希望這些做的人就會(huì)反對(duì)說(shuō)這樣是行不通的,但是事實(shí)是擺在面前。

??? 為了實(shí)現(xiàn)簡(jiǎn)易的剖析,可以當(dāng)job中一些task運(yùn)行很慢時(shí),用ssh工具連接上task所在的那臺(tái)task tracker機(jī)器。執(zhí)行5到10次這個(gè)簡(jiǎn)單的命令 sudo killall -QUIT java (每 次執(zhí)行間隔幾秒)。別擔(dān)心,不要被命令的名字嚇著,它不會(huì)導(dǎo)致任何東西退出。然后使用JobTracker的界面跳轉(zhuǎn)到那臺(tái)機(jī)器上某個(gè)task的 stdout 文件上,或者查看正在運(yùn)行的機(jī)器上/var/log/hadoop/userlogs/目錄中那個(gè)task的stdout文件。你就可以看到當(dāng)你執(zhí)行那段 命令時(shí),命令發(fā)送到JVM的SIGQUIT信號(hào)而產(chǎn)生的棧追蹤信息的dump文件。([ ] 在JobTracker的界面上有Cluster Summary的表格,進(jìn)入Nodes鏈接,選中你執(zhí)行上面命令的server,在界面的最下方有Local Logs,點(diǎn)擊LOG進(jìn)入,然后選擇userlogs目錄,這里可以看到以server執(zhí)行過(guò)的jobID命名的幾個(gè)目錄,不管進(jìn)入哪個(gè)目錄都可以看到很 多task的列表,每個(gè)task的log中有個(gè)stdout文件,如果這個(gè)文件不為空,那么這個(gè)文件就是作者所說(shuō)的棧信息文件)

??? 解析處理這個(gè)輸出文件需要一點(diǎn)點(diǎn)以經(jīng)驗(yàn),這里我介紹下平時(shí)是怎樣處理的:
對(duì)于棧信息中的每個(gè)線程,很快地查找你的java包的名字(假如是com.mycompany.mrjobs)。如果你當(dāng)前線程的棧信息中沒(méi)有找到任何與你的代碼有關(guān)的信息,那么跳到另外的線程再看。

??? 如果你在某些棧信息中看到你查找的代碼,很快地查閱并大概記下它在做什么事。假如你看到一些與NumberFormat相關(guān)的信息,那么此時(shí)你需要記下它,暫時(shí)不需要關(guān)注它是代碼的哪些行。

??? 轉(zhuǎn)到日志中的下一個(gè)dump,然后也花一些時(shí)間做類似的事情然后記下些你關(guān)注的內(nèi)容。

??? 在查閱了4到5個(gè)棧信息后,你可能會(huì)意識(shí)到在每次查閱時(shí)都會(huì)有一些似曾相識(shí)的東西。如果這些你意識(shí)到的問(wèn)題是阻礙你的程序變快的原因,那么你可能就找到了 程序真正的問(wèn)題。假如你取到10個(gè)線程的棧信息,然后從5個(gè)里面看到過(guò)NumberFormat類似的信息,那么可能意味著你將50%的CPU浪費(fèi)在數(shù)據(jù) 格式轉(zhuǎn)換的事情上了。

??? 當(dāng)然,這沒(méi)有你使用真正的分析程序那么科學(xué)。但我發(fā)現(xiàn)這是一種有效的方法,可以在不需要引入其它工具的時(shí)候發(fā)現(xiàn)那些明顯的CPU瓶頸。更重要的是,這是一種讓你會(huì)變的更強(qiáng)的技術(shù),你會(huì)在實(shí)踐中知道一個(gè)正常的和有問(wèn)題的dump是啥樣子。

??? 通過(guò)這項(xiàng)技術(shù)我發(fā)現(xiàn)了一些通常出現(xiàn)在性能調(diào)優(yōu)方面的誤解,列出在下面。
1. NumberFormat 相當(dāng)慢,盡量避免使用它。
2. String.split—不管是編碼或是解碼UTF8的字符串都是慢的超出你的想像— 參照上面提到的建議,使用合適的Writable類型。
3. 使用StringBuffer.append來(lái)連接字符串

??? 上面只是一些提高M(jìn)apReduce性能的建議。做基準(zhǔn)測(cè)試的那些代碼我放在了這里: performance blog code

原文:? 7 Tips for Improving MapReduce Performance

:MapReduce: 提高M(jìn)apReduce性能的七點(diǎn)建議[譯]


更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號(hào)聯(lián)系: 360901061

您的支持是博主寫(xiě)作最大的動(dòng)力,如果您喜歡我的文章,感覺(jué)我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長(zhǎng)非常感激您!手機(jī)微信長(zhǎng)按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對(duì)您有幫助就好】

您的支持是博主寫(xiě)作最大的動(dòng)力,如果您喜歡我的文章,感覺(jué)我的文章對(duì)您有幫助,請(qǐng)用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長(zhǎng)會(huì)非常 感謝您的哦!!!

發(fā)表我的評(píng)論
最新評(píng)論 總共0條評(píng)論
主站蜘蛛池模板: 亚洲 欧美 另类 天天更新影院 | 国产日韩欧美在线一区二区三区 | 伊人75| 激情综合色综合久久综合 | 国内精品一级毛片免费看 | 夜夜骑狠狠干 | 激情国产视频 | 日本综合欧美一区二区三区 | 奇米亚洲春色 | 在线观看国产视频 | 狠狠色噜噜狠狠狠狠网站视频 | 亚欧成人毛片一区二区三区四区 | 日韩天天摸天天澡天天爽视频 | 97看片网| 久久国产欧美日韩高清专区 | 亚洲一区二区精品视频 | 国内精品久久久久久麻豆 | 一级毛片看真人在线视频 | 亚洲国产精久久久久久久春色 | 香蕉成人在线视频 | 97av麻豆蜜桃一区二区 | 日日天干夜夜人人添 | 四虎最新网址入口 | 神马影院我不卡影院 | 欧美色视频日本片高清在线观看 | 一级毛片 在线播放 | 天天操天天射天天操 | 美女毛片 | 欧美一级毛片一级 | 四虎麻豆 | 国产日韩一区二区 | 奇米色第四色 | 久久一本色道综合 | 日本欧美一区二区三区乱码 | 亚洲成人中文字幕 | 女人182毛片a级毛片 | 亚洲日韩欧洲无码av夜夜摸 | 成人精品综合免费视频 | 九九精品国产兔费观看久久 | 久久好看视频 | 伊人精品视频一区二区三区 |