latencia e overhead
ajuda com alguns termos diferentes, estou lendo e vendo algumas video aulas sobre replicação, o que é latencia e overhead?
Mariana Carvalho
Curtidas 0
Melhor post
Mariana Carvalho
03/10/2014
Não precisa se desculpar, vou ver os links.
GOSTEI 1
Mais Respostas
Mariana Carvalho
15/09/2014
????????????????
GOSTEI 0
Mariana Carvalho
15/09/2014
ajudem!!!!
GOSTEI 0
João Françozo
15/09/2014
Bom dia Mariana,
O precisa saber sobre replicação.
O precisa saber sobre replicação.
GOSTEI 0
Mariana Carvalho
15/09/2014
Eu não se fazer mas tenho uma ideia/entedimento, queria saber mais sobre latencia e overhead.
GOSTEI 0
João Françozo
15/09/2014
Bom dia Mariana,
Cada sessão de usuário pode ter uma ou mais tarefas sendo executadas em seu nome, sendo que cada tarefa pode adquirir ou aguardar para adquirir uma variedade de recursos. Os tipos de recursos a seguir podem causar bloqueio que pode resultar em um deadlock.
Bloqueios. A espera para adquirir bloqueios em recursos, como objetos, páginas, linhas, metadados e aplicativos pode causar deadlock. Por exemplo, a transação T1 tem um bloqueio compartilhado (S) na linha r1 e está esperando para obter um bloqueio exclusivo (X) em r2. A transação T2 tem um bloqueio compartilhado (S) na linha r1 e está esperando para obter um bloqueio exclusivo (X) em r1. Isso resulta em um ciclo de bloqueio no qual T1 e T2 esperam que uma libere os recursos bloqueados da outra.
Threads de trabalho Uma tarefa em fila aguardando um thread de trabalho pode causar um deadlock. Se a tarefa em fila possuir recursos que estão bloqueando todos os threads de trabalhado, haverá um deadlock. Por exemplo, a sessão S1 inicia uma transação e adquire um bloqueio compartilhado (S) na linha r1 e, depois, fica suspenso. As sessões ativas em execução em todos os threads de trabalhado disponíveis estão tentando adquirir bloqueios exclusivos (X) na linha r1. Como a sessão S1 não pode adquirir um thread de trabalho, ela não pode confirmar a transação e liberar o bloqueio na linha r1. Isso resulta em um deadlock.
Memória. Quando solicitações simultâneas estão esperando por concessões de memória que não podem ser satisfeitas com a memória disponível, pode ocorrer um deadlock. Por exemplo, duas consultas simultâneas, Q1 e Q2, são executadas como funções definidas pelo usuário que adquirem 10MB e 20MB de memória, respectivamente. Se cada consulta precisar de 30MB e a memória disponível total for de 20MB, Q1 e Q2 deverão esperar uma pela outra para liberar memória. Isso resulta em um deadlock.
Recursos relacionados à execução de consultas paralelas Threads de coordenação, produção ou consumo associados a uma porta de troca podem bloquear um ao outro causando um deadlock, normalmente ao incluir pelo menos um outro processo que não faz parte da consulta paralela. Além disso, quando uma consulta paralela começa a ser executada, o SQL Server determina o grau de paralelismo, ou o número de threads de trabalho, com base na carga de trabalho atual. Se a carga de trabalho do sistema for alterada inesperadamente, por exemplo, quando novas consultas forem executadas no servidor ou o sistema ficar sem threads de trabalho, poderá ocorrer um deadlock.
Recursos de vários conjuntos de resultados ativos (MARS). Esses recursos são usados para controlar a intercalação de várias solicitações ativas em MARS (consulte Ambiente de execução em lote e MARS).
Recurso do usuário. Quando um thread está esperando por um recurso que é potencialmente controlado por um aplicativo de usuário, o recurso é considerado como externo ou recurso de usuário e é tratado como um bloqueio.
Mutex de sessão. As tarefas que estão sendo executadas em uma sessão são intercaladas, ou seja, apenas uma tarefa pode ser executada na sessão em um determinado momento. Antes de a tarefa ser executada, deve ter acesso exclusivo ao mutex de sessão.
Mutex de transação. Todas as tarefas que estão sendo executadas em uma transação são intercaladas, ou seja, somente uma tarefa pode ser executada na transação em um determinado momento. Antes da tarefa ser executada, deve ter acesso exclusivo ao mutex de transação.
Para que uma tarefa seja executada em MARS, ela deve adquirir o mutex da sessão. Se a tarefa estiver sendo executada em uma transação, deverá adquirir o mutex de transação. Isso garante que apenas uma tarefa esteja ativa em um determinado momento, sessão e transação. Quando os mutexes solicitados forem adquiridos, a tarefa poderá ser executada. Quando a tarefa termina, ou está no meio da solicitação, primeiro ela libera o mutex de transação e, depois, o mutex de sessão em ordem reversa de aquisição. Porém, podem ocorrer deadlocks com esses recursos. No exemplo de código a seguir, duas tarefas, solicitação de usuário U1 e solicitação de usuário U2, estão sendo executadas na mesma sessão.
Att
João Antonio
Cada sessão de usuário pode ter uma ou mais tarefas sendo executadas em seu nome, sendo que cada tarefa pode adquirir ou aguardar para adquirir uma variedade de recursos. Os tipos de recursos a seguir podem causar bloqueio que pode resultar em um deadlock.
Bloqueios. A espera para adquirir bloqueios em recursos, como objetos, páginas, linhas, metadados e aplicativos pode causar deadlock. Por exemplo, a transação T1 tem um bloqueio compartilhado (S) na linha r1 e está esperando para obter um bloqueio exclusivo (X) em r2. A transação T2 tem um bloqueio compartilhado (S) na linha r1 e está esperando para obter um bloqueio exclusivo (X) em r1. Isso resulta em um ciclo de bloqueio no qual T1 e T2 esperam que uma libere os recursos bloqueados da outra.
Threads de trabalho Uma tarefa em fila aguardando um thread de trabalho pode causar um deadlock. Se a tarefa em fila possuir recursos que estão bloqueando todos os threads de trabalhado, haverá um deadlock. Por exemplo, a sessão S1 inicia uma transação e adquire um bloqueio compartilhado (S) na linha r1 e, depois, fica suspenso. As sessões ativas em execução em todos os threads de trabalhado disponíveis estão tentando adquirir bloqueios exclusivos (X) na linha r1. Como a sessão S1 não pode adquirir um thread de trabalho, ela não pode confirmar a transação e liberar o bloqueio na linha r1. Isso resulta em um deadlock.
Memória. Quando solicitações simultâneas estão esperando por concessões de memória que não podem ser satisfeitas com a memória disponível, pode ocorrer um deadlock. Por exemplo, duas consultas simultâneas, Q1 e Q2, são executadas como funções definidas pelo usuário que adquirem 10MB e 20MB de memória, respectivamente. Se cada consulta precisar de 30MB e a memória disponível total for de 20MB, Q1 e Q2 deverão esperar uma pela outra para liberar memória. Isso resulta em um deadlock.
Recursos relacionados à execução de consultas paralelas Threads de coordenação, produção ou consumo associados a uma porta de troca podem bloquear um ao outro causando um deadlock, normalmente ao incluir pelo menos um outro processo que não faz parte da consulta paralela. Além disso, quando uma consulta paralela começa a ser executada, o SQL Server determina o grau de paralelismo, ou o número de threads de trabalho, com base na carga de trabalho atual. Se a carga de trabalho do sistema for alterada inesperadamente, por exemplo, quando novas consultas forem executadas no servidor ou o sistema ficar sem threads de trabalho, poderá ocorrer um deadlock.
Recursos de vários conjuntos de resultados ativos (MARS). Esses recursos são usados para controlar a intercalação de várias solicitações ativas em MARS (consulte Ambiente de execução em lote e MARS).
Recurso do usuário. Quando um thread está esperando por um recurso que é potencialmente controlado por um aplicativo de usuário, o recurso é considerado como externo ou recurso de usuário e é tratado como um bloqueio.
Mutex de sessão. As tarefas que estão sendo executadas em uma sessão são intercaladas, ou seja, apenas uma tarefa pode ser executada na sessão em um determinado momento. Antes de a tarefa ser executada, deve ter acesso exclusivo ao mutex de sessão.
Mutex de transação. Todas as tarefas que estão sendo executadas em uma transação são intercaladas, ou seja, somente uma tarefa pode ser executada na transação em um determinado momento. Antes da tarefa ser executada, deve ter acesso exclusivo ao mutex de transação.
Para que uma tarefa seja executada em MARS, ela deve adquirir o mutex da sessão. Se a tarefa estiver sendo executada em uma transação, deverá adquirir o mutex de transação. Isso garante que apenas uma tarefa esteja ativa em um determinado momento, sessão e transação. Quando os mutexes solicitados forem adquiridos, a tarefa poderá ser executada. Quando a tarefa termina, ou está no meio da solicitação, primeiro ela libera o mutex de transação e, depois, o mutex de sessão em ordem reversa de aquisição. Porém, podem ocorrer deadlocks com esses recursos. No exemplo de código a seguir, duas tarefas, solicitação de usuário U1 e solicitação de usuário U2, estão sendo executadas na mesma sessão.
Att
João Antonio
GOSTEI 0
Mariana Carvalho
15/09/2014
João Antonio, obrigada mesmo pelas otimas informações, eu tinha até uma certa noção dos termos T1, T2...mas está com um longo tempo, aonde posso encontrar e qual o nome especifico para eu pesquisar depois?
GOSTEI 0
Alex Lekao
15/09/2014
Nao sei se seria o caso, mas segue mais material. rssr
Latencia
[url:descricao=Como medir a latência e validar conexões para replicação de transação (Programação Transact-SQL de replicação)]http://technet.microsoft.com/pt-br/library/ms147309(v=sql.105).aspx[/url]
[url:descricao=Medindo a latência e validando as conexões para a replicação de transação]http://msdn.microsoft.com/pt-br/library/ms151178(v=sql.105).aspx[/url]
Overhead, acredito eu que seja basicamente uma sobrecarga que podem acontecer com praticamente tudo. rsrsr
so vai depender de utilizacao de boas praticas entre outros cuidados a serem tomados para nao causar essa sobrecarga.
Mas nao sou expert, entao, me desculpe se estiver errado. rsrsr
Abraco.
Latencia
[url:descricao=Como medir a latência e validar conexões para replicação de transação (Programação Transact-SQL de replicação)]http://technet.microsoft.com/pt-br/library/ms147309(v=sql.105).aspx[/url]
[url:descricao=Medindo a latência e validando as conexões para a replicação de transação]http://msdn.microsoft.com/pt-br/library/ms151178(v=sql.105).aspx[/url]
Overhead, acredito eu que seja basicamente uma sobrecarga que podem acontecer com praticamente tudo. rsrsr
so vai depender de utilizacao de boas praticas entre outros cuidados a serem tomados para nao causar essa sobrecarga.
Mas nao sou expert, entao, me desculpe se estiver errado. rsrsr
Abraco.
GOSTEI 0
Alex Lekao
15/09/2014
BLZ!!
=D
=D
GOSTEI 0
Mariana Carvalho
15/09/2014
Entendi, é para ser estudado em ambientes grandes em que as consultas e inserções são consideraveis e que podem afetar de algum modo a operacionalidade do banco, é isso?
GOSTEI 0
Alex Lekao
15/09/2014
Honestamente eu nao sou entendedor do assunto. rssr
Mas acredito que sim.
Acredito que empresas de porte pegueno nao se preocupem com isso, muito provavelmente serao empresas muito grandes com bancos tao grandes o quanto, e utilizando sistemas ERP de alto custo, que possivelmente tenham esse tipo de necessidade e monitoria.
Mas acredito que sim.
Acredito que empresas de porte pegueno nao se preocupem com isso, muito provavelmente serao empresas muito grandes com bancos tao grandes o quanto, e utilizando sistemas ERP de alto custo, que possivelmente tenham esse tipo de necessidade e monitoria.
GOSTEI 0
Mariana Carvalho
15/09/2014
Obrigada, estava suspeitando disso e é até meio que está informação está na "cara" mas é sempre bom ter certeza!
GOSTEI 0
Alex Lekao
15/09/2014
Eh, eu imagino que seja referente a isso mesmo.
Mas, como disse, nao sou entendedor do assunto, basicamente supus. rsrsr
Mas, como disse, nao sou entendedor do assunto, basicamente supus. rsrsr
GOSTEI 0
Mariana Carvalho
15/09/2014
Tambem estou achando...irei atras de mais leituras, obrigada pela ajuda.
GOSTEI 0
Alex Lekao
15/09/2014
disponha.
=D
=D
GOSTEI 0