Power BI Premium Metrics uygulamasıPower BI Premium Metrics app

Power BI Premium Metrics uygulamasını, Power BI Premium aboneliğinizin durumunu ve kapasitesini yönetmek için kullanabilirsiniz.You can use the Power BI Premium Metrics app to manage the health and capacity of your Power BI Premium subscription. Bu uygulamayla, yöneticiler uygulamanın Kapasite durumu merkezi’ni kullanarak premium kapasitelerinin durumunu izleyen göstergeleri görebilir ve bunlarla etkileşimli çalışabilir.With the app, administrators use the app's Capacity health center to see and interact with indicators that monitor the health of their premium capacity. Metrics uygulaması Kapasite Durumu Merkezi adlı bir giriş sayfasından ve üç önemli ölçümün ayrıntılarından oluşur:The Metrics app consists of the landing page, called the Capacity Health Center, and details about three important metrics:

  • Etkin bellekActive memory
  • Sorgu beklemeleriQuery waits
  • Yenileme beklemeleriRefresh waits

Power BI Premium Metrics uygulaması

Aşağıdaki bölümlerde giriş sayfası ve üç ölçüm raporu sayfası ayrıntılarıyla açıklanır.The following sections describe the landing page, and the three metrics report pages, in detail.

Önemli

Power BI Premium kapasitenizde performans ve güvenilirlik sorunlarına neden olan yüksek kaynak kullanımı sorunu yaşanıyorsa sorunu tanımlayıp çözmek için bildirim e-postaları alabilirsiniz.If your Power BI Premium capacity is experiencing high resource usage, resulting in performance or reliability issues, you can receive notification emails to identify and resolve the issue. Bu, aşırı yüklenmiş kapasitelerde sorun gidermeye yönelik basitleştirilmiş bir yöntemdir.This can be a streamlined way to troubleshoot overloaded capacities. Daha fazla bilgi için bkz. Kapasite ve güvenilirlik bildirimleri.See capacity and reliability notifications for more information.

Premium kapasite durumu merkeziPremium capacity health center

Power BI Premium Metrics uygulamasını açtığınızda Power BI Premium kapasitenizin durumuna genel bir bakış sağlayan Kapasite durumu merkezi gösterilir.When you open the Power BI Premium metrics app you're presented with the Capacity health center, which provides an overview of the health of your Power BI Premium capacity.

Premium Metrics uygulamasında kapasite durumu merkezi

Kuruluşunuzun birden çok Premium aboneliği olması durumunda, giriş sayfasında görüntülemek istediğiniz Power BI Premium kapasiteyi seçebilirsiniz.From the landing page, you can select the Power BI Premium capacity you want to view, in case your organization has multiple Premium subscriptions. Premium kapasiteyi görüntülemek için sayfanın üst kısmındaki Ölçümlerini görmek için bir kapasite seçin adlı açılan listesi seçin.To view a Premium capacity, select the dropdown near the top of the page called Select a capacity to see its metrics.

Üç KPI, bunların her birine uygulanan ayarlar temelinde, seçilen Premium kapasitenin geçerli durumunu gösterir.The three KPIs show the current health of the selected Premium capacity, based on the settings applied to each of the three KPIs.

KPI’ler hakkındaki özel değerleri görüntülemek için her KPI’nin altındaki Araştır düğmesini seçin; KPI’nin ayrıntılar sayfası görüntülenir.To view specifics about each KPI, select the Explore button at the bottom of each KPI's visual, and its detail page is displayed. Aşağıdaki bölümlerde KPI’ler ve sayfalarında sağlanan ayrıntılar açıklanır.The following sections describe each KPI and the details its page provides.

Etkin bellek ölçümüThe active memory metric

Etkin bellek ölçümü kapasite planlaması kategorisinde yer alır. Bu kategori kullanım için kapasitenizin kaynak tüketimini değerlendirmenizi, dolayısıyla kapasite ölçeğini planlarken gereken kapasiteyi ayarlayabilmenizi sağlayan iyi bir göstergedir.The active memory metric is part of the capacity planning category, which is a good health indicator to evaluate your capacity's resource consumption for usage, so you can adjust the capacity as necessary to plan capacity scale.

Etkin bellek KPI

Etkin bellek şu anda kullanımda olan, dolayısıyla bellek gerektiğinde çıkarılmayacak veri kümelerini işlemek için kullanılan bellektir.Active memory is the memory used to process datasets that are currently in use, and which therefore will not be evicted when memory is needed. Etkin bellek ölçümü kapasitenizin ek yükü işleyip işleyemeyeceğini ya da geçerli yükün kapasitesine yaklaşıldığını veya bu kapasitenin aşıldığını gösterir.The active memory metric indicates whether your capacity can handle additional load, or of already nearing or over capacity, the capacity's current load. Etkin belleğin şu anda tüketiliyor olması, ek yenileme ve sorguları desteklemek için kullanılabilecek daha az bellek olduğu anlamına gelir.The active memory currently being consumed means less memory is available to support additional refreshes and queries.

Etkin bellek KPI kapasitenin etkin belleğinin 50 kez %70 eşiğini geçme durumuyla kaç kez karşılaştığını ölçer (işaretçi son yedi günün %30’una ayarlanmıştır); bu ölçüm kapasitenin sorgularda kullanıcının performans sorunlarıyla karşılaşmaya başlayabileceği bir noktaya yaklaştığını gösterir.The active memory KPI measures how many times the capacity's active memory has crossed the 70% threshold 50 times (the marker is set to 30% of the last seven days), which indicates that the capacity is approaching a point when users may begin seeing performance issues with queries.

Bu bölümde gösterilen ölçer görseli raporun son yenilenmesinden bu yana geçen son yedi günde kapasitenin %70 eşiğini dört kez aştığını, saatlik demetlere bölünmüş olarak ortaya koymaktadır.The gauge visual shown in this section reveals that, in the last seven days from the time the report was last refreshed, the capacity has crossed the 70% threshold four times, split by hourly buckets. Ölçerin en yüksek değeri olan 168, saat cinsinden son yedi günü temsil eder.The maximum value of the gauge, 168, represents the last seven days, in hours.

Etkin bellek KPI’nin ayrıntılarını öğrenmek için Araştır düğmesine tıklayarak ayrıntılı ölçümlerinin belirli görselleştirmelerini sağlayan rapor sayfasına bakabilirsiniz. Ayrıca bu sayfanın sağ sütununda bir sorun giderme kılavuzu da gösterilir.To learn the details of the active memory KPI, click the Explore button to see a report page that provides specific visualizations of its detailed metrics, along with a troubleshooting guide shown on the right column of the page.

İki senaryo açıklanmıştır; rapor sayfasında Senaryo 1 veya Senaryo 2’yi seçerek bunları görüntüleyebilirsiniz.There are two scenarios explained, which you can show on the report page by selecting Scenario 1 or Scenario 2 on the page.

Etkin bellek ayrıntı sayfası

Her senaryoyla ilişkilendirilmiş sorun giderme kılavuzları ölçümlerin ne anlama geldiğine ilişkin ayrıntılı açıklamalar sağlar. Böylelikle kapasitenin durumunu ve varsa sorunları azaltmak için ne yapılabileceğini daha iyi anlayabilirsiniz.The troubleshooting guides, associated with each scenario, provide detailed explanations about what the metrics mean, so you can better understand the state of the capacity, and what can be done to mitigate any issues.

Bu iki senaryo aşağıdaki bölümlerde açıklanmıştır.Those two scenarios are described in the following sections.

Senaryo bir - geçerli yük fazla büyükScenario one - current load is too high

Kapasitenin iş yüklerini tamamlamasına yetecek kadar bellek olup olmadığını saptamak için sayfadaki ilk görsele başvurun: A: Tüketilen Bellek Yüzdeleri, şu anda etkin olarak işlenen ve bu nedenle çıkarılamayacak olan veri kümelerinin tükettiği belleği görüntüler.To determine whether there's enough memory for the capacity to complete its workloads, consult the first visual on the page: A: Consumed Memory Percentages, which displays the memory consumed by datasets that are being actively processed, and thus, cannot be evicted.

Kırmızı noktalı çizgiyle gösterilen alarm eşiği %90 bellek tüketimi durumlarına işaret eder.The alarm threshold, which is the red dotted line, marks incidents of 90% memory consumption.

Sarı noktalı çizgiyle gösterilen uyarı eşiği %70 bellek tüketimi durumlarına işaret eder.The warning threshold, which is the yellow dotted line, marks incidents of 70% memory consumption.

Siyah noktalı çizgi, grafiğin zaman çizelgesi boyunca geçerli kapasitenin bellek kullanımına dayanarak bellek kullanımının eğilim çizgisini gösterir.The black dotted line indicates the memory usage trendline, based on the current capacity's memory usage over the course of the graph timeline.

Etkin belleğin alarm eşiğinin (kırmızı noktalı çizgi) ve bellek eğilim çizgisinin (siyah noktalı çizgi) üzerine çıktığı durumlar bellek kapasitesi baskısı olduğunu gösterir; bu süre boyunca başka veri kümelerinin belleğe yüklenmesi büyük olasılıkla engellenir.High occurrences of active memory above the alarm threshold (red dotted line) and memory trendline (black dotted line) indicates memory capacity pressure, possibly preventing additional datasets from being loaded into memory during that time.

Böyle durumlarla karşılaştığınızda, şu anda neden bu kadar sıklıkta bu kadar fazla bellek tüketildiğini ve yükün nasıl dengeleneceğini veya iyileştirileceğini ya da kapasitenin ölçeğini artırmanın gerekip gerekmediğini daha iyi saptamak için sayfadaki diğer grafikleri dikkatle gözden geçirmelisiniz.When you see such cases, you should look carefully at the other charts on the page to better determine what and why so much memory is so frequently being consumed, and how to load balance or optimize, or if necessary, scale up the capacity.

Sayfadaki diğer görsel olan B: Saatlik yüklenen etkin veri kümeleri, saatlik demetler halinde belleğe yüklenmiş olan veri kümelerinin maksimum sayısını görüntüler.The second visual on the page, B: Hourly loaded active datasets displays the counts of the maximum number of datasets that were loaded in memory, in hourly buckets.

Üçüncü görsel olan C: Veri kümeleri neden bellekte, veri kümesini çalışma alanı adı, veri kümesi adı, bellekte veri kümelerinin sıkıştırılmamış boyutuna göre listeleyen ve belleğe neden yüklendiğini açıklayan (yenileniyor, sorgulandı veya her ikisi gibi) bir tablodur.The third visual, C: Why datasets are in memory is a table that lists the dataset by workspace name, dataset name, datasets uncompressed size in memory, explains the reason it's loaded in memory (such as, being refreshed or queried against, or both).

Senaryo bir için tanılamaDiagnosing scenario one

Tutarlı yüksek bellek kullanımı, şu anda etkin bir şekilde kullanılan veri kümelerini çıkarmaya zorlayabilir veya yeni veri kümelerinin yüklenmesini engelleyebilir.Consistent high active memory utilization may result in forcing datasets that are actively being used to be evicted, or can prevent new datasets from able to load. Aşağıdaki adımlar sorunları tanılamanıza yardımcı olabilirThe following steps can help you diagnose problems

  1. A: Tüketilen bellek yüzdeleri grafiğine bakınHave a look at chart A: Consumed memory percentages

    a.a. Grafik A’da alarm eşiğinin (%90) birçok kez ve/veya birbirini izleyen saatlerde aşıldığını gösteriyorsa, kapasiteniz yetersiz bellek durumuyla fazla sık karşılaşıyor demektir.If Chart A shows the alarm threshold (90%) is crossed many times and/or for consecutive hours, then your capacity is running low on memory too frequently. Aşağıdaki grafikte uyarı eşiğinin (%70) dört kez aşıldığını görebiliriz.In the chart below, we can see the warning threshold (70%) was crossed four times.

    Grafik a, tüketilen bellek yüzdeleri

    b.b. B: Saatlik yüklenen etkin veri kümeleri, saatlik demetler halinde belleğe yüklenmiş olan benzersiz veri kümelerinin maksimum sayısını gösterir.The chart titled B: Hourly loaded active datasets shows the maximum number of unique datasets loaded in memory by hourly buckets. Görselde bir çubuk seçildiğinde veri kümelerinin bellek görselinde olma nedenlerine çapraz filtre uygulanır.Selecting a bar in the visual will cross filter the reasons datasets are in memory visual.

    Grafik b, saate göre tüketilen bellek

    c.c. Belleğe yüklenen veri kümelerinin listesini görmek için Veri kümeleri neden bellekte tablosuna başvurun.Consult the Why datasets are in memory table to see a list of the datasets that were loaded in memory. En fazla bellek kullanan veri kümelerini vurgulamak için Veri Kümesi Boyutu (MB) alanına göre sıralayın.Sort by Dataset Size (MB) to highlight the datasets taking up the most memory. Kapasite işlemleri etkileşimli veya arka plan olarak sınıflandırılır.Capacity operations are classified as either interactive or background. Etkileşimli işlemler isteklerin işlenmesini ve kullanıcı etkileşimlerine (filtreleme ve Soru-Cevap sorgulama gibi) yanıt verilmesini içerir.Interactive operations include rendering requests and responding to user interactions (filtering, Q&A querying, and so on). Toplam sorgu sayısı ve toplam yenileme sayısı, veri kümesinde ağır etkileşimli işlemlerin mi (sorgular) yoksa arka plan işlemlerinin mi (yenilemeler) gerçekleştirildiğine ilişkin bir fikir sağlar.Total queries and total refreshes provide an idea of whether there are interactive (queries) heavy or background (refreshes) operations done on the dataset. Mümkün olan en iyi kullanıcı deneyimini sağlamak için etkileşimli işlemlerin her zaman arka plan işlemlerinden daha öncelikli olduğunun anlaşılması önemlidir.It's important to understand that interactive operations are always prioritized over background operations to ensure the best possible user experience. Kaynaklar yetersizse arka plan işlemleri kuyruğa eklenir ve kaynaklar serbest kaldığında işlenir.If there are insufficient resources, background operations are added to a queue, and are processed once resources free up. Veri kümesi yenilemeleri ve yapay zeka işlevleri gibi arka plan işlemleri, işlemin ortasında Power BI hizmeti tarafından durdurulabilir ve kuyruğa eklenebilir.Background operations, such as dataset refreshes and AI functions, can be stopped mid-process by the Power BI service and added to a queue.

    tablo c, veri kümelerinin listesi

Senaryo bir için düzeltmelerRemedies for scenario one

Senaryo bir ile ilişkilendirilmiş sorunları düzeltmek için aşağıdaki adımları uygulayabilirsiniz:You can take the following steps to remedy the problems associated with scenario one:

  1. Kapasitenin ölçeğini artırın - Kapasitenin ölçeği bir sonraki SKU’ya artırıldığında geçerli SKU’nun iki katı kadar bellek miktarı kullanıma sunulduğundan, kapasitede şu anda yaşanan bellek baskısı hafifletilir.Scale up the capacity - scaling up the capacity to the next SKU will make available twice the amount of memory than the current SKU, thus alleviating any memory pressure the capacity is currently experiencing.

  2. Veri kümelerini başka bir kapasiteye taşıyın - Daha fazla kullanılabilir belleğe sahip başka bir kapasiteniz varsa, büyük veri kümelerini içeren çalışma alanlarını o kapasiteye taşıyabilirsiniz.Move datasets to another capacity - if you have another capacity that has more memory available, you can move the workspaces that contain the larger datasets to that capacity.

Senaryo iki - yük gelecekte sınırları aşacakScenario two - future load will exceed limits

Kapasitenin iş yüklerini tamamlamasına yetecek kadar bellek olup olmadığını saptamak için sayfadaki üst kısmında yer alan A: Tüketilen Bellek Yüzdeleri, görseline başvurabilirsiniz. Bu görsel şu anda etkin olarak işlenen ve bu nedenle çıkarılamayacak olan veri kümelerinin tükettiği belleği temsil eder.To determine whether there's enough memory for the capacity to complete its workloads, you can refer to the A: Consumed Memory Percentages visual on the top of the page, representing the memory consumed by datasets that are being actively processed so cannot be evicted. Siyah noktalı çizgi eğilimleri vurgular.The black dotted line highlights the trends. Bellek baskısıyla karşılaşılan kapasitede aynı görsel bellek eğilim çizgisinin (siyah noktalı çizgi) açıkça yukarı doğru çıktığını gösterecektir. Bunun anlamı, zamanın bu noktasında ek veri kümelerini belleğe yüklemenin büyük olasılıkla engellendiğidir.In a capacity experiencing memory pressure, the same visual will clearly show the memory trendline (black dotted line) upwards, meaning that it is possibly preventing additional datasets from being loaded into memory at that point in time. Siyah noktalı eğilim çizgisi yedi günlük verilere dayanarak büyüme eğilimini gösterir.The trend line, the black dashed line, shows the trend of growth based on the seven days of data.

Etkin bellek ayrıntı sayfası

Senaryo iki için tanılamaDiagnosing scenario two

Senaryo iki’yi tanılamak için eğilim çizgisinin yukarıya, uyarı ve alarm eşiklerine doğru bir eğilim gösterip göstermediğini saptayın.To diagnose scenario two, determine if the trend line is showing an upward trend towards warning or alarm thresholds.

  1. Şu grafiğe bakın: Grafik A:Consider Chart A:

    Tüketilen bellek grafiği

    a.a. Grafikte yukarı doğru bir eğim gösteriliyorsa, bellek tüketimi son yedi günde artmış demektir.If the chart shows an upward slope, that indicates that memory consumption has increased over the past seven days.

    b.b. Geçerli büyümeyi düşünerek eğilim çizgisinin uyarı eşiğini (sarı noktalı çizgi) ne zaman geçeceğini tahmin edin.Assume the current growth, and predict when the trend line will cross the warning threshold (the yellow dashed line).

    c.c. Eğilimin devam edip etmediğini görmek için en azından iki günde bir eğilim çizgisini gözden geçirmeye devam edin.Keep checking the trend line at least every two days, to see if the trend continuing.

Senaryo iki için düzeltmelerRemedies for scenario two

Senaryo iki ile ilişkilendirilmiş sorunları düzeltmek için aşağıdaki adımları uygulayabilirsiniz:You can take the following steps to remedy the problems associated with scenario two:

  1. Kapasitenin ölçeğini artırın - Kapasitenin ölçeği bir sonraki SKU’ya artırıldığında geçerli SKU’nun iki katı kadar bellek miktarı kullanıma sunulduğundan, kapasitede şu anda yaşanan bellek baskısı hafifletilir.Scale up the capacity - scaling up the capacity to the next SKU will make available twice the amount of memory than the current SKU, thus alleviating any memory pressure the capacity is currently experiencing.

  2. Veri kümelerini başka bir kapasiteye taşıyın - Daha fazla kullanılabilir belleğe sahip başka bir kapasiteniz varsa, büyük veri kümelerini içeren çalışma alanlarını o kapasiteye taşıyabilirsiniz.Move datasets to another capacity - if you have another capacity that has more memory available, you can move the workspaces that contain the larger datasets to that capacity.

Sorgu bekleme ölçümüThe query waits metric

Sorgular kategorisi kullanıcıların yavaş yanıt veren veya yanıt vermeyi durduran rapor görselleriyle karşılaşıp karşılaşmayacağını gösterir.The Queries category indicates whether users could experience report visuals that are slow to respond, or could become unresponsive. Sorgu beklemeleri sorgunun tetiklenmesinden yürütülmeye başlamasına kadar geçen süredir.Query waits is the time the query takes to start execution from the time it was triggered. Bu KPI seçilen kapasitedeki sorguların %25’inde veya daha çoğunda sorgunun yürütülmesi için 100 milisaniye beklenip beklenmediğini ölçer.This KPI measures whether 25% or more of the selected capacity's queries are waiting 100 milliseconds or longer to execute. Sorgu beklemeleri, tüm bekleyen sorguların yürütülmesi için yeterli kullanılabilir CPU olmadığında ortaya çıkar.Query waits occur when there's not enough available CPU to execute all pending queries.

Sorgu beklemeleri ölçeri

Bu görseldeki ölçer raporun son yenilenmesinin ardından geçen yedi gün boyunca sorguların %17,32’sinin 100 milisaniyeden fazla beklediğini gösteriyor.The gauge in this visual shows that in the last seven days from the time the report was last refreshed, 17.32% of the queries waited more than 100 milliseconds.

Sorgu beklemeleri KPI’nin ayrıntılarını öğrenmek için Araştır düğmesine tıklayarak uygun ölçümlerin görsellerini içeren rapor sayfasını ve sayfanın sağ sütununda sorun giderme kılavuzunu görüntüleyin.To learn details of Query waits KPI, click the Explore button to display a report page with visualization of relevant metrics, and a troubleshooting guide in the right column of the page. Sorun giderme senaryosunun iki senaryosu vardır. Senaryolardan her biri ölçümün ayrıntılı açıklamalarını, kapasitenin durumunu ve sorunu hafifletmek için neler yapabileceğinizi gösterir.The troubleshooting guide has two scenarios, each providing detailed explanations of the metric, the state of the capacity, and what you can do to mitigate the issue.

Aşağıdaki bölümlerde sırasıyla iki sorgu beklemeleri senaryosunu da anlatacağız.We discuss each query waits scenario, in turn, in the following sections.

Senaryo bir - uzun süre çalışan sorgular CPU’yu tüketiyorScenario one - long running queries consume CPU

Senaryo bir’de uzun süre çalışan sorgular çok fazla CPU kullanıyor.In scenario one, long running queries are taking up too much CPU.

Düşük rapor performansının aşırı yüklenen kapasiteden mi yoksa yanlış tasarlanmış veri kümesi veya rapordan mı kaynaklandığını araştırabilirsiniz.You can investigate whether poor report performance is caused by an overloaded capacity, or due to a poorly designed dataset or report. Uzun süre çalışan sorgular, yürütmesini tamamlamanın 10 saniyeden uzun sürdüğü sorgular olarak tanımlanır ve sorgunun uzun süre çalışmasının çeşitli nedenleri vardır.There are several reasons why a query can run for an extended period, which is defined as taking more than 10 seconds to finish executing. Örneğin veri kümesinin boyutu ve karmaşıklığı ile sorgu karmaşıklığı, sorgunun uzun süre çalışmasının olası nedenlerinden yalnızca birkaçıdır.Dataset size and complexity, as well as query complexity are just a few examples of what can cause a long running query.

Rapor sayfasında aşağıdaki görseller görüntülenir:On the report page, the following visuals appear:

  • Üstte yer alan A: Uzun bekleme süreleri tablosunda bekleyen sorguların bulunduğu veri kümeleri listelenir.The top table titled A: High wait times lists the datasets with queries that are waiting.
  • B: Saatlik uzun bekleme süresi dağılımları, uzun bekleme sürelerinin dağılımını gösterir.B: Hourly high wait time distributions shows the distribution of high wait times.
  • C: Saatlik uzun sorgu sayıları başlıklı grafikte yürütülmüş olan uzun çalışan sorguların saatlik demetler halinde sayısı görüntülenir.The chart titled C: Hourly long query counts displays the count of long running queries that were executed split by hourly buckets.
  • Son görsel olan D: Uzun süre çalışan sorgular tablosunda uzun süre çalışan sorgular ve onların istatistikleri listelenir.The last visual, table D: Long running queries, lists the long running queries and their stats.

Sorgu beklemeleri ayrıntılar sayfası

Sorgu bekleme sürelerini tanılamak ve gidermek için izleyebileceğiniz adımlar vardır ve bunlar aşağıda açıklanmıştır.There are steps you can take to diagnose and remedy issues with query wait times, described next.

Senaryo bir için tanılamaDiagnosing scenario one

İlk olarak sorguların uzun süre çalışma durumunun sorgularınız beklerken mi gerçekleştiğini saptayın.First, you can determine if long running queries are occurring when your queries are waiting.

Uzun bekleme süreleri tablosu

100 ms’den fazla bekleyen sorguların sayısını gösteren Grafik B’ye bakın.Look at Chart B, which shows the count of queries that are waiting more than 100 ms. Yüksek bekleme sayısı gösteren sütunlardan birini seçin.Select one of the columns that shows a high number of waits.

Uzun bekleme süresi dağılımı

Uzun bekleme süreleri içeren bir sütuna tıkladığınızda, aşağıdaki resimde gösterildiği gibi Grafik C bu süre içinde yürütülen ve uzun süre çalışan sorguların sayısını gösterecek şekilde filtrelenir:When you click on a column with high wait times, Chart C is filtered to show the count of long-running queries that executed during that time, shown in the following image:

Saatlik uzun süre çalışan sorgu sayısı

Buna ek olarak Grafik D de seçilen zaman aralığı içinde uzun süre çalışmış olan sorgular gösterilecek şekilde filtrelenir.And in addition, Chart D is also filtered to show the queries that were long running during that selected time period.

Uzun süre çalışan sorgular

Senaryo bir için düzeltmelerRemedies for scenario one

Senaryo bir’deki sorunları gidermek için izleyebileceğiniz adımlar şunlardır:Here are steps you can take to remedy issues from scenario one:

  1. Raporları ve veri kümelerini iyileştirmek için PerfAnalyzer çalıştırın - Raporlar için performans analizi, her görselin ne kadar sürede yenilendiği ve zamanın nereye harcandığı da dahil olmak üzere sayfadaki her etkileşimin etkisini gösterir.Run PerfAnalyzer to optimize reports and datasets - the performance analyzer for reports will show the effect of every interaction on a page, including how long each visual takes to refresh and where the time is spent.

  2. Kapasitenin ölçeğini artırın - Kapasitenin ölçeği bir sonraki SKU’ya artırıldığında kullanılabilir CPU miktarı iki katına çıktığından, sorguların uzun süre çalışmasına neden olabilen CPU baskısı hafifletilir.Scale up the capacity - scaling up the capacity to the next SKU will make available twice the amount of CPU thus alleviating any CPU pressure that may be causing the queries to run longer.

  3. Veri kümelerini başka bir kapasiteye taşıyın - Daha fazla kullanılabilir CPU’ya sahip başka bir kapasiteniz varsa, bekleyen sorguların bulunduğu veri kümelerini içeren çalışma alanlarını o kapasiteye taşıyabilirsiniz.Move datasets to another capacity - if you have another capacity that has more CPU available, you can move the workspaces that contain the datasets that contain the queries that are waiting to the other capacity.

Senaryo iki - çok fazla sorguScenario two - too many queries

Senaryo iki’de çok fazla sorgu yürütülmektedir.In scenario two, too many queries are executing.

Yürütülecek sorguların sayısı kapasitenin sınırlarını aştığında, sorguları yürütmek için gereken kaynaklar kullanılabilir duruma gelene kadar sorgular kuyruğa alınır.When the number of queries to execute exceeds the limits of the capacity, queries are placed in a queue until resources are available to execute them. Kuyruğun boyutu çok fazla büyürse, sonunda söz konusu kuyruktaki sorgular 100 milisaniyeden daha fazla beklemek zorunda kalabilir.If the size of the queue grows too large, queries in that queue can end up waiting more than 100 milliseconds.

Senaryo iki

Senaryo iki için tanılamaDiagnosing scenario two

Tablo A’dan bekleme süresi oranı yüksek bir veri kümesi seçin.From Table A select a dataset that has a high percentage of wait time.

uzun bekleme süreleri tablosu

Siz uzun bekleme süresi olan bir veri kümesi seçtikten sonra, Grafik B söz konusu veri kümesindeki sorgular için son yedi gündeki bekleme süresi dağılımlarını gösterecek şekilde filtrelenir.Once you've selected a dataset with a high wait time, Chart B is filtered to show the wait time distributions for queries on that dataset, over the past seven days. Sonra Grafik B’deki sütunlardan birini seçin.Next, select one of the columns from Chart B.

saatlik uzun bekleme süreleri dağılım grafiği

Ardından Grafik C, kuyruğun Grafik B’den seçildiği sıradaki uzunluğunu gösterecek şekilde filtrelenir.Chart C is then filtered to show the queue length at the time selected from Chart B.

saatlik sorgu kuyruğu uzunluğu

Kuyruğun uzunluğu 20 eşiğini aştıysa, aynı anda yürütülmeye çalışılan sorgu sayısı çok fazla olduğundan büyük olasılıkla seçilen veri kümesindeki sorgular geciktirilir.If the length of the queue has crossed the threshold of 20, then it's likely that the queries in the selected dataset are delayed, due to too many queries trying to execute at the same time.

Yürütülen sorgular tablosu

Senaryo iki için düzeltmelerRemedies for scenario two

Senaryo iki ile ilişkilendirilmiş sorunları düzeltmek için aşağıdaki adımları uygulayabilirsiniz:You can take the following steps to remedy the problems associated with scenario two:

  1. Kapasitenin ölçeğini artırın - Kapasitenin ölçeği bir sonraki SKU’ya artırıldığında geçerli SKU’nun iki katı kadar bellek miktarı kullanıma sunulduğundan, kapasitede şu anda yaşanan bellek baskısı hafifletilir.Scale up the capacity - scaling up the capacity to the next SKU will make available twice the amount of memory than the current SKU, thus alleviating any memory pressure the capacity is currently experiencing.

  2. Veri kümelerini başka bir kapasiteye taşıyın - Daha fazla kullanılabilir belleğe sahip başka bir kapasiteniz varsa, büyük veri kümelerini içeren çalışma alanlarını o kapasiteye taşıyabilirsiniz.Move datasets to another capacity - if you have another capacity that has more memory available, you can move the workspaces that contain the larger datasets to that capacity.

Yenileme beklemeleri ölçümüThe refresh waits metric

Yenileme beklemeleri ölçümü kullanıcıların eski rapor verileriyle karşılaşabileceği durumlarla ilgili içgörü sağlar.The Refresh waits metric provides insights to when users could be experiencing report data that's old or stale. Yenileme beklemeleri, belirli bir veri yenilemesinin isteğe bağlı veya zamanlanmış olarak tetiklendiği zamandan başlayarak, yürütülmeden önce beklediği süredir.Refresh waits is the time a given data refresh waited to start execution, from the time it was triggered on demand, or scheduled to run. Bu KPI bekleyen yenileme isteklerinin %10’unun veya daha fazlasının 10 dakika veya daha uzun süre bekleyip beklemediğini gösterir.This KPI measures whether 10% or more of pending refresh requests are waiting 10 minutes or longer. Bekleme durumları genellikle kullanılabilir belleğin veya CPU’nun yetersiz olduğu zamanlarda yaşanır.Waiting generally occurs when there's insufficient available memory or CPU.

Yenileme beklemeleri ölçeri

Bu ölçer son rapor yenilemesinden sonraki yedi gün içinde yenilemelerden %3,18’inin 10 dakikadan fazla beklediğini göstermektedir.This gauge shows that in the last seven days from the last refresh report refresh, 3.18% of the refreshes waited more than 10 minutes.

Yenileme beklemeleri KPI’nin ayrıntılarını öğrenmek için Araştır düğmesine tıklayın. Ölçümleri ve rapor sayfasının sağ sütununda sorun giderme kılavuzunu içeren bir sayfa görüntülenir.To learn the details of the Refresh waits KPI, click the Explore button, which presents a page with metrics and a troubleshooting guide on the right column of the report page. Kılavuz sayfadaki ölçümler hakkında ayrıntılı açıklamalar sağlar, ayrıca kapasitenin durumunu ve sorunları gidermek için neler yapabileceğinizi anlamanıza yardımcı olur.The guide provides detailed explanations about the metrics on the page, and helps you understand the state of the capacity, and what you can do to mitigate any issues.

Yenileme beklemeleri ölçümlerini inceleme

İki senaryo açıklanmıştır; rapor sayfasında Senaryo 1 veya Senaryo 2’yi seçerek bunları görüntüleyebilirsiniz.There are two scenarios explained, which you can show on the report page by selecting Scenario 1 or Scenario 2 on the page. Aşağıdaki bölümlerde sırasıyla iki senaryoyu da anlatacağız.We discuss each scenario in turn, in the following sections.

Senaryo bir - bellek yetersizScenario one - not enough memory

Senaryo bir’de veri kümesini yüklemek için yeterli bellek yoktur.In scenario one, there isn't enough available memory to load the dataset. Yetersiz bellek koşullarında yenilemenin azaltılmasıyla sonuçlanan iki durum vardır:There are two situations that result in a refresh being throttled during low memory conditions:

  1. Veri kümesini yüklemek için bellek yeterli değil.Not enough memory to load the dataset.
  2. Daha yüksek öncelikli bir işlemden dolayı yenileme iptal edildi.The refresh was canceled due to a higher priority operation.

Veri kümelerini yükleme önceliği şöyledir:The priority for loading datasets is the following:

  1. Etkileşimli SorguInteractive query
  2. İsteğe bağlı yenilemeOn-demand refresh
  3. Zamanlanmış yenilemeScheduled refresh

Etkileşimli sorguda veri kümesini yüklemek için yeterli bellek yoksa, zamanlanan yenilemeler durdurulur ve yeterli bellek kullanılabilir duruma gelene kadar bu yenilemelerin veri kümeleri kaldırılır.If there isn't enough memory to load a dataset for an interactive query, scheduled refreshes are stopped and their datasets unloaded until sufficient memory become available. Bu işlem yeterli belleğin serbest bırakılmasını sağlamazsa, isteğe bağlı yenilemeler durdurulur ve onların veri kümeleri kaldırılır.If that doesn't free up enough memory, then on-demand refreshes are stopped and their datasets are unloaded.

Senaryo bir için tanılamaDiagnosing scenario one

Senaryo bir’de tanılama için önce azaltmanın yetersiz bellekten kaynaklanıp kaynaklanmadığını saptayın.To diagnose scenario one, first determine whether throttling is due to insufficient memory. Bu işlemin adımları aşağıda verilmiştir.The steps to do so are the following.

  1. Tablo A’da ilgilendiğiniz veri kümesini tıklayarak seçin:Select the dataset you're interested in from Table A by clicking on it:
![Tablo A](media/service-premium-metrics-app/premium-metrics-app-22.png)

<span data-ttu-id="0a200-276">a.</span><span class="sxs-lookup"><span data-stu-id="0a200-276">a.</span></span> <span data-ttu-id="0a200-277">**Tablo A**’da veri kümesi seçildiğinde **Grafik B** beklemenin ne zaman oluştuğunu gösterecek şekilde filtrelenir.</span><span class="sxs-lookup"><span data-stu-id="0a200-277">When a dataset is selected in **Table A**, **Chart B** is filtered to show when waiting occurred.</span></span>

![Grafik B](media/service-premium-metrics-app/premium-metrics-app-23.png)

<span data-ttu-id="0a200-279">b.</span><span class="sxs-lookup"><span data-stu-id="0a200-279">b.</span></span> <span data-ttu-id="0a200-280">Ardından **Grafik C** herhangi bir azaltmayı gösterecek şekilde filtrelenir (sonraki adımda açıklanmıştır).</span><span class="sxs-lookup"><span data-stu-id="0a200-280">**Chart C** is then filtered to show any throttling, explained in the next step.</span></span> 
  1. Artık filtrelenmiş olan Grafik C’deki sonuçları gözden geçirin. Grafik, veri kümesi beklerken bellek yetersiz azaltması oluştuğunu gösteriyorsa, veri kümesinin beklemesinin nedeni yetersiz bellek koşullarıdır.Look at the results in the now-filtered Chart C. If the chart shows out of memory throttling occurred at the times the dataset was waiting, then the dataset was waiting due to low memory conditions.

    Grafik C

  2. Son olarak, gerçekleşen yenilemelerin türünü (zamanlanmış veya isteğe bağlı) gösteren Grafik D’yi denetleyin.Finally, check Chart D, which shows the types of refreshes that were occurring, scheduled versus on-demand. Azaltmanın nedeni aynı anda gerçekleşen isteğe bağlı yenilemeler olabilir.Any on-demand refreshes occurring at the same time could be the cause of the throttling.

    Grafik D

Senaryo bir için düzeltmelerRemedies for scenario one

Senaryo bir ile ilişkilendirilmiş sorunları düzeltmek için aşağıdaki adımları uygulayabilirsiniz:You can take the following steps to remedy the problems associated with scenario one:

  1. Kapasitenin ölçeğini artırın - Kapasitenin ölçeği bir sonraki SKU’ya artırıldığında geçerli SKU’nun iki katı kadar bellek miktarı kullanıma sunulduğundan, kapasitede şu anda yaşanan bellek ve CPU baskısı hafifletilir.Scale up the capacity - scaling up the capacity to the next SKU will make available twice the amount of memory than the current SKU, thus alleviating any memory and CPU pressure the capacity is currently experiencing.

  2. Veri kümelerini başka bir kapasiteye taşıyın - Bekleme sürelerinizin nedeni bellek baskısıysa ve daha fazla kullanılabilir belleğe sahip başka bir kapasiteniz varsa, bekleyen veri kümelerini içeren çalışma alanlarını o kapasiteye taşıyabilirsiniz.Move datasets to another capacity - if your wait times are being caused by memory pressure and you have another capacity that has more memory available, you can move the workspaces that contain the datasets that are waiting to the other capacity.

  3. Zamanlanan yenilemeleri yayın - Yenilemelerin yayılması çok fazla yenilemenin eşzamanlı olarak yürütülmeye çalışılmasını önlemeye yardımcı olur.Spread out scheduled refreshes - spreading out the refreshes will help to avoid too many refreshes attempting to execute concurrently.

Senaryo iki - yenileme için CPU yeterli değilScenario two - not enough CPU for refresh

Senaryo iki’de yenilemeyi gerçekleştirmek için yeterli kullanılabilir CPU yok.In scenario two, there isn't enough available CPU to carry out the refresh.

Ayrılmış kapasiteler için Power BI eşzamanlı olarak gerçekleşebilecek yenileme sayısını sınırlar.For dedicated capacities, Power BI limits the number of refreshes that can happen concurrently. Bu sayı, arka uç çekirdeklerinin sayısı x 1,5’e eşittir.This number is equal to the number of back-end cores x 1.5. Örneğin dört arka uç çekirdeği olan bir P1 ayrılmış kapasitesi eşzamanlı olarak 6 yenileme çalıştırabilir.For example, a P1 dedicated capacity, which has four back-end cores, can run 6 refreshes concurrently. Eşzamanlı yenileme sayısı üst sınırına ulaşıldığında, diğer yenilemeler yürütülen yenilemelerin bitmesini bekler.Once the maximum number of concurrent refreshes has been reached, other refreshes will wait until an executing refresh finishes.

Yenileme için senaryo iki

Senaryo iki için tanılamaDiagnosing scenario two

Senaryo iki’de tanılama yapmak için önce azaltmanın eşzamanlı yenileme sayısı üst sınırına ulaşılmasından mı kaynaklandığını saptayın.To diagnose scenario two, first determine whether throttling is due to running into the maximum concurrency for refreshes. Bu işlemin adımları aşağıda verilmiştir.The steps to do so are the following.

  1. Tablo A’da ilgilendiğiniz veri kümesini tıklayarak seçin:Select the dataset you're interested in from Table A by clicking on it:
![Tablo A](media/service-premium-metrics-app/premium-metrics-app-22.png)

<span data-ttu-id="0a200-303">a.</span><span class="sxs-lookup"><span data-stu-id="0a200-303">a.</span></span> <span data-ttu-id="0a200-304">**Tablo A**’da veri kümesi seçildiğinde **Grafik B** beklemenin ne zaman oluştuğunu gösterecek şekilde filtrelenir.</span><span class="sxs-lookup"><span data-stu-id="0a200-304">When a dataset is selected in **Table A**, **Chart B** is filtered to show when waiting occurred.</span></span>

![Grafik B](media/service-premium-metrics-app/premium-metrics-app-23.png)

<span data-ttu-id="0a200-306">b.</span><span class="sxs-lookup"><span data-stu-id="0a200-306">b.</span></span> <span data-ttu-id="0a200-307">Ardından **Grafik C** herhangi bir azaltmayı gösterecek şekilde filtrelenir (sonraki adımda açıklanmıştır).</span><span class="sxs-lookup"><span data-stu-id="0a200-307">**Chart C** is then filtered to show any throttling, explained in the next step.</span></span> 
  1. Artık filtrelenmiş olan Grafik C’deki sonuçları gözden geçirin. Grafik, veri kümesi beklerken oluşan en fazla eşzamanlılık değerini gösteriyorsa veri kümesinin beklemesinin nedeni kullanılabilir CPU’nun yeterli olmamasıdır.Look at the results in the now-filtered Chart C. If the chart shows max concurrency occurred at the times the dataset was waiting, then the dataset was waiting due to not enough available CPU.

    Grafik C

  2. Son olarak, gerçekleşen yenilemelerin türünü (zamanlanmış veya isteğe bağlı) gösteren Grafik D’yi denetleyin.Finally, check Chart D, which shows the types of refreshes that were occurring, scheduled versus on-demand. Azaltmanın nedeni aynı anda gerçekleşen isteğe bağlı yenilemeler olabilir.Any on-demand refreshes occurring at the same time could be the cause of the throttling.

    Grafik D

Senaryo iki için düzeltmelerRemedies for scenario two

  1. Kapasitenin ölçeğini artırın - Kapasitenin ölçeği bir sonraki SKU’ya artırıldığında geçerli SKU’nun iki katı kadar bellek miktarı ve geçerli SKU’dan iki kat fazla eşzamanlı yenileme sayısı kullanıma sunulduğundan, kapasitede şu anda yaşanan bellek ve CPU baskısı hafifletilir.Scale up the capacity - scaling up the capacity to the next SKU will make available twice the amount of memory than the current SKU, and twice the number of concurrent refreshes than the current SKU, thus alleviating any memory and CPU pressure the capacity is currently experiencing.

  2. Veri kümelerini başka bir kapasiteye taşıyın - Bekleme sürelerinizin nedeni eşzamanlılık sayısı üst sınırına ulaşılmasıysa ve daha fazla kullanılabilir eşzamanlılığa sahip başka bir kapasiteniz varsa, bekleyen veri kümelerini içeren çalışma alanlarını o kapasiteye taşıyabilirsiniz.Move datasets to another capacity - if your wait times are being caused by maximum concurrency being reached and you have another capacity that has available concurrency, you can move the workspaces that contain the datasets that are waiting to the other capacity.

  3. Zamanlanan yenilemeleri yayın - Yenilemelerin yayılması çok fazla yenilemenin eşzamanlı olarak yürütülmeye çalışılmasını önlemeye yardımcı olur.Spread out scheduled refreshes - spreading out the refreshes will help to avoid too many refreshes attempting to execute concurrently.

Sonraki adımlarNext steps

Başka bir sorunuz mu var?More questions? Power BI Topluluğu'na sorunTry asking the Power BI Community