在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

鍍金池/ 問答
艷骨 回答

click時間冒泡,觸發(fā)了document上的點擊事件
<div class="dropdown" @click.stop='toggleDropdownMenu($event)'>
這樣寫應(yīng)該就不會執(zhí)行了

尋仙 回答

你這個寫法應(yīng)該是 vue-router 吧， vue-router 常見有三種格式的路由守衛(wèi):

1) 全局路由守衛(wèi)

如 beforeEach， afterEach

2) 路由獨享守衛(wèi)

如 beforeEnter

3) 組件獨享守衛(wèi)

如 beforeRouterEnter， beforeRouterUpdate， beforeRouterLeave

他們的應(yīng)用場景各不相同，你問的太寬泛，所以都有可能。

陌南塵 回答

有這么幾種可能

  • 百度統(tǒng)計沒有正確安裝，少統(tǒng)計某一種設(shè)備什么的
  • 百度統(tǒng)計本身不是實時的，對于你們來說有滯后
  • 用戶網(wǎng)絡(luò)狀況，手速太快等等原因?qū)е掳俣冉y(tǒng)計根本沒起作用

對了，還有種可能是這些沒被統(tǒng)計的注冊用戶都是機(jī)器人

兔寶寶 回答

一般跟配置文件的env屬性有關(guān)，不知道有沒有聲明'es6':true？

瘋子范 回答 
old_str = '/opt/www/html'
new_str = old_str.replace('/', '\/')
print(new_str)
淚染裳 回答

你這樣關(guān)聯(lián)字段來判斷是否已讀消息不科學(xué)啊，后期數(shù)據(jù)量大起來的話很難受的

一般都是消息表有個狀態(tài)字段來區(qū)分它們，比如：

—————————————————————————————————————————
| Id | 編號 |
—————————————————————————————————————————
| State | 消息狀態(tài)：1 未讀 2 已讀 |
—————————————————————————————————————————

關(guān)聯(lián)還是 messageId 與 消息表 Id 關(guān)聯(lián)

但查詢未讀消息的話就這樣

SELECT * FROM [message] WHERE State=1

豈不美哉！??！

乞許 回答

右邊一個iframe點擊運行重新加載？

祉小皓 回答

1.方案一把默認(rèn)授權(quán)的admin給刪掉
2.方案二在首頁的effects里做判斷,然后使用window.location.href

安淺陌 回答

定義了一個數(shù)組，保存了圖片的src信息。

var imgs = ['1.jpg', '2.jpg','3.jpg'];

調(diào)用resetImgs函數(shù)時，根據(jù)參數(shù)dir來判斷是上一張圖片還是下一張圖片。
如果是上一張圖片，就執(zhí)行_setPrevImgs
如果是下一張圖片，就執(zhí)行_setNextImgs
這兩個函數(shù)對curImg進(jìn)行修改，改變curImg即當(dāng)前圖片的值。

不懂可以繼續(xù)問~

尐懶貓 回答

下次記得把原始查詢也發(fā)出來，我們看著更方便些。從執(zhí)行計劃來反推，查詢大約是

db.webDevice.find({
    lid: {
        $in: [
            "40CnwyHkVmnA9kbScMLNLneaxuS4Tcj",
            "140CnwyHkVmnA9kbScMLNLneaxuS4Tcj"
        ]
    }
}).sort({createTime: -1}).limit(1);

因為命中索引，這個查詢獲取數(shù)據(jù)的速度實際上比較快，你也提到在一段時間內(nèi)第二次查詢就快了，這是一個很明顯的特點，代表內(nèi)存不足。MongoDB和其他數(shù)據(jù)庫一樣，都會使用空閑內(nèi)存緩沖索引和數(shù)據(jù)，當(dāng)內(nèi)存不足時就會使用LRU算法清理舊數(shù)據(jù)換入新數(shù)據(jù)再繼續(xù)查詢。因為這個過程涉及到磁盤數(shù)據(jù)交換，速度會大大降低。發(fā)生這種情況有一個特點，就是一段時間內(nèi)第二次執(zhí)行時速度就快了（因為數(shù)據(jù)已經(jīng)在內(nèi)存中）。但是如果過一段時間再執(zhí)行，速度又會變慢（因為又被換出內(nèi)存了）。所以你的情況實際上就是受限于硬件。
既然如此最直接的解決辦法就是：

  1. 使用更快的硬盤；
  2. 使用更大的內(nèi)存；

如果不能從硬件方面解決，有一點可以嘗試就是用CPU換內(nèi)存。做法是盡可能調(diào)小cacheSizeGB（是的沒錯，是調(diào)?。？臻e出來的內(nèi)存操作系統(tǒng)會用來緩沖磁盤數(shù)據(jù)，而磁盤數(shù)據(jù)是經(jīng)過壓縮的，體積更小，因此可以緩沖更多數(shù)據(jù)到內(nèi)存中。但作為交換，在使用這些數(shù)據(jù)時需要經(jīng)過CPU再進(jìn)行一次解壓從而額外消耗CPU。即使這樣，效果也比從磁盤讀取要好很多。整個過程是自動進(jìn)行的，你需要做的只是調(diào)小cacheSizeGB。
這種做法可以在一定程度上緩解內(nèi)存不足的問題，但不是萬能的：

  • 首先它會增加CPU消耗，如果你的系統(tǒng)本身已經(jīng)沒有剩余的CPU資源，這種做法就不合適；
  • 其次受制于壓縮率，這樣做之后內(nèi)存能容納的數(shù)據(jù)并不會比以前多很多，所以并不是萬能的；

補(bǔ)充回答

基于你的新的疑問，以下幾點補(bǔ)充：

疑問1: 按照你說的方式調(diào)小cacheSizeGB,應(yīng)該怎么調(diào)整比較合理

我在上面有提到，這樣做的效果有限，是受制于壓縮率的限制。所以多容納的數(shù)據(jù)實際就是壓縮的數(shù)據(jù)。比如1G的內(nèi)存能放多少數(shù)據(jù)？

  • 如果不壓縮（壓縮率100%），1G內(nèi)存能放1GB數(shù)據(jù)；
  • 如果壓縮率90%，1G內(nèi)存可以放10/9GB~=1.11數(shù)據(jù)；
  • 如果壓縮率80%，1G內(nèi)存可以放10/8 = 1.25GB數(shù)據(jù)；
  • 以此類推……

所以調(diào)到多少，其實要看你想往內(nèi)存里放多少數(shù)據(jù)，而這往往是一個不確定的數(shù)值。這里會有另外一個概念叫做工作集（working set），就是你經(jīng)常用到的那些數(shù)據(jù)。比如你的數(shù)據(jù)庫共有100GB數(shù)據(jù)，但是你經(jīng)常用到的部分只有10GB，那么你的內(nèi)存只要能裝下10GB數(shù)據(jù)，應(yīng)用在大部分時候就可以非?？?，剩下的情況忽略就好了。
基于上面這些分析，你應(yīng)該可以算一下，你的工作集有多大，數(shù)據(jù)壓縮率有多大，那么需要把cacheSizeGB調(diào)到多小才能容納下工作集（又或者調(diào)到多小都不可能容納下工作集）。你的情況是內(nèi)存不足CPU空閑，所以如果懶得算，直接把cacheSizeGB調(diào)到最小值就好了。

疑問2: config只用了1.5GB內(nèi)存(限制了CacheSizeGB3GB).可以說明索引都加載到了內(nèi)存中嗎?

這說明config數(shù)據(jù)庫（元數(shù)據(jù)）的索引和數(shù)據(jù)都加載到內(nèi)存中了。注意數(shù)據(jù)的索引肯定是在shard中，與config無關(guān)。而且大頭是在shard上面。
順便提一下，如果不是實驗?zāi)康?，根本沒必要分這么多片。因為在一臺機(jī)器上分再多片，硬件資源也只有這么多，對于性能沒有什么意義，反而還會有額外的傳輸開銷。

疑問3: mongodb remove數(shù)據(jù)后,查詢卻越來越慢是什么情況?

remove之后跟查詢沒有本質(zhì)上的聯(lián)系，可能只是湊巧發(fā)生在一起。如果你有足夠的證據(jù)覺得這兩者確實有聯(lián)系，請另開問題描述清楚問題的上下文以及你發(fā)現(xiàn)的情況，必要的時候也可以求助于MongoDB JIRA。如果一定要做一個無根據(jù)的猜測，我覺得可能是remove時導(dǎo)致熱數(shù)據(jù)被換出內(nèi)存（注意remove也需要先找到滿足條件的數(shù)據(jù)然后才能刪除），引起后面的查詢需要重新從磁盤上加載數(shù)據(jù)造成的。

怣痛 回答

clipboard.png
拖動所選文件，直到出現(xiàn)透明狀陰影，便可以進(jìn)行分屏操作
clipboard.png
clipboard.png

櫻花霓 回答

大致可以這樣：

//遍歷所有page節(jié)點
selectorQuery()

//遍歷所有組件節(jié)點
for(let component of components )
selectorQuery.in(component)

憶往昔 回答

vue-loader里面已經(jīng)有對sass-loader的配置，你把你的配置刪掉試試？

瘋子范 回答

看這個報錯信息應(yīng)該是vue-tinymce-editor不支持服務(wù)器端渲染

在這個組件外部dom元素上加一個判斷

<div v-if="!$isServer">這里放vue-tinymce-editor試試</div>
櫻花霓 回答

  1. app.vue 傳遞，good.vue 接收:

    export default {
    props: {
          seller: {
            type: Object
          }
    }
 }

  2. good.vue 傳遞，shopcart.vue 接收

    export default {
    props: {
          deliveryPrice: {
            type: Number,
            default: 0
          },
          minPrice: {
            type: Number,
            default: 0
          }
        }
 }
首頁 上一頁 222 223 224 225 226 227 228 229 230 下一頁 尾頁