- This topic has 3 replies, 2 voices, and was last updated 6 years, 3 months ago by José Laurindo Chiappa.
-
AuthorPosts
-
3 de agosto de 2018 at 11:26 pm #109359sergiomsoParticipant
Caros colegas
Um parametro chato de entender. Alguem sabe o impacto de desabilitar o parametro filesystemio_options para ‘NOME’? Na minha base esta setado com SETALL. Eu li alguma coisa sobre seu respeito. Ele aumenta mesmo o I/O dos processos Oracle ou não.
NAME TYPE VALUE
———————————— ———– ——————————
filesystemio_options string SETALLObrigado
3 de agosto de 2018 at 11:41 pm #109360José Laurindo ChiappaModerator“Aumenta” no sentido de forçar o RDBMS a fazer mais I/Os, é isso ? Se for isso Não, de forma alguma : o que esse param faz é permitir ou não acesso direto ao arquivo que o Oracle precisa (bypassando os caches do Sistema Operacional, o que via de regra é BOM pra performance, pois o Oracle já possui e mantém seus caches próprios – usar caches do SO além dos caches do Oracle é só overhead via de regra) , e Também permitir I/O asíncrono : o I/O asíncrono é um I/O no qual o RDBMS não fica “CONGELADO”, esperando o Sistema Operacional terminar completamente a operação de I/O : com I/O Async ativo, o RDBMS pede pro Sistema Operacional fazer um I/O e imediatamente já começa a trabalhar em outras coisas, ao invés de ficar “parado” esperando o Sistema Operacional terminar o I/O e sinalizar que tudo foi bem…. OU SEJA : num hardware e num SO que permitam, se vc setar tudo o RDBMS vai passar a bypassar controles e caches do Sistema Operacional (e passar a usar os dele, muito mais eficientes) E vai passar a não ficar ‘congelado’ esperando o sistema operacional terminar um I/O : via de regra o Sistema Operacional e um hardware server-class tem TOTAL capacidade de receberem múltiplas solicitações por parte do RDBMS ao invés de uma só….
Sendo assim, via de regra esse parâmetro DEVE SIM estar setado – Desde Que o seu hardware+Sistema Operacional SUPORTE Direct I/O e Async I/O ele deveria estar como SETALL, se teu hw+SO só suporta DIrect I/O sete pra DIRECTIO, e se só suporta ASYNC sete pra isso : pra mais explicações, veja http://facedba.blogspot.com/2015/11/direct-and-asynchronous-io-setup-in.html , http://www.dba-oracle.com/oracle_tips_direct_io.htm e https://oracle-base.com/articles/misc/direct-and-asynchronous-io : basicamente vão te dizer o mesmo que eu disse. é o que é ….
[]s
Chiappa
6 de agosto de 2018 at 5:22 pm #109362sergiomsoParticipantMuito Obrigado
CHIAPPA
Pelos esclarecimento e visão técnica.
6 de agosto de 2018 at 8:10 pm #109363José Laurindo ChiappaModeratorBlz, fico contente de poder ter ajudado… Espero que tenham ficado Claro os trade-offs / escolhas/ consequências de cada tipo de I/O :
-> no caso de Direct I/O , primeiro vc está POUPANDO o sistema operacional de ter que alocar alguns ciclos de CPU pra controlar buffers E (já que como sabemos o Oracle mantém caches próprios, via de regra isso é double-caching, algo que pode implicar em desperdícios de recursos) : o trade-off é que vc passa a ter TODAS as leituras feitas pelo Sistema Operacional diretamente como Physical I/O – num sistema ‘mal comportado’ onde a toda hora são solicitados dados completamente diferentes com pouca chance de estarem no cache Oracle, a ausência do cache do SO PODE levar a situações anômalas, cfrme https://www.linkedin.com/pulse/20140515000229-1093877-oracle-file-system-buffer-cache-vs-direct-io e https://asktom.oracle.com/pls/asktom/f?p=100%3A11%3A%3A%3A%3A%3AP11_QUESTION_ID%3A7931107631402 por exemplo exemplificam uns casos…
-> no caso do I/O Asíncrono, há uma questão mais sutil : digamos que o sistema seja mal-desenvolvido e porcamente implementado, e entre outras coisas esteja fazendo Toneladas de I/O , e isso num sub-sistema de I/O não tão ‘potente’, sem poder pra atender mais do que uns pouquinhos I/Os simultâneos… Num ambiente assim, digamos que não está implementado o AIO e portanto aquela sessão que acabeou de pedir o I/O ‘congela’ uns milisegundos enquanto espera o I/O que acabou de pedir ser completado : esse ‘refresco’, esse “tempinho” sem novas solicitações é o tempinho que o sub-sistema de I/O tem pra ‘respirar’, pra poder fazer as suas atividades…. Aí o DBA sem analisar/sem saber disso ativa o Async I/O – com ele o que acontecerá é que a sessão que acabou de pedir um I/O não vai dar NENHUMA folga pro sub-sistema de I/O, mesmo sem ter recebido a resposta sobre esse I/O que acabou de pedir a sessão já vai mandar OUTRA e OUTRA requisição pro Sistema Operacional, que DEIXOU DE TER esse tempinho de respiro…. O que vai acontecer é simplesmente um AFOGAMENTO, esse sub-sistema de I/O simplesmente ficou ASSOBERBADO de coisas a fazer…
===>>> OU SEJA : antes de sair setando ou não o parâmetro, ENTENDA o que ele faz, CONHEÇA como está o regime de uso do ser hardware (em especial CPU e I/O) e só então vc vai TESTAR….
[]s
Chiappa
-
AuthorPosts
- You must be logged in to reply to this topic.