De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
Colaboração: Rubens Queiroz de Almeida
Data de Publicação: 11 de agosto de 2010
Este texto foi traduzido e adaptado a partir de trechos selecionados do original em inglês, de autoria de Eric Raymond, publicado no site Linux.org, no documento The Unix Hardware Buyer HOWTO, parte 4, What To Optimize.
Esta seção é uma cortesia de Perry, o Cínico, <<perry (a) sutr cynic orgr>>; foi escrita em 1998. Minha experiência concorda completamente com a dele. Eu fiz uma revisão dos números para refletir os avanços mais recentes na tecnologia.)
Construir um bom subsistema de I/O se resume a dois pontos principais: escolha componentes que sejam compatíveis, de modo a não super especificar qualquer parte por nada, e construa a tubulação de forma a que possa alimentar o combo do sistema operacional/aplicação conforme necessário.
É importante reconhecer que o "equilíbrio" se refere não apenas a um subsistema participar de processador e memória, mas também a um tipo particular de sistema operacional e aplicativos. Um servidor Unix rodando a suíte de protocolos TCP/IP completa tem requisitos de I/O radicalmente diferentes de um sistema para edição de vídeos. Um bom consultor irá coletar amostras das demandas de I/O (através da leitura de logs de desempenho do sistema ou através de novas medições) e calcular o tamanho que o sistema de I/O precisa ter para satisfazer o conjunto de aplicativos. Isto não é algo que o seu comprador Linux típico deseja fazer; o conjunto de aplicativos não é estático e irá mudar com o tempo. Ao invés disto, o que você irá fazer, é projetar um subsistema de I/O que seja internamente coerente e que ofereça o máximo potencial de desempenho de I/O pelo dinheiro que você está disposto a gastar. Então você olha para os patamares de preços e os compara com aqueles para o subsistema de memória. Esta é a decisão mais importante dentro da caixa.
Então, a tarefa agora é projetar e comprar um subsistema de I/O que seja bem sintonizado para oferecer o melhor retorno em termos de investimento. Os dois números mais importantes para I/O de disco são a latência e a largura de banda. Latência é o tempo que um programa tem que esperar para obter um pedaço dos dados aleatórios que solicitou. Largura de banda é quantos dados contíguos podem ser enviados de/para o disco uma vez que você já tenha feito a primeira parte. A latência é medida em milisegundos (ms); a largura de banda é medida em megabytes por segundo (MB/s). Obviamente, um terceiro número de interesse é o tamanho total de seus discos (quanto de espaço de armazenamento você possui), em gigabytes (GB).
Contemplando um cenário mais amplo, minimizar a latência é o pulo do gato. Cada milisegundo que você economizar no tempo efetivo de latência tornará o seu sistema significativamente mais rápido. A largura de banda, por outro lado, apenas ajuda se você lê um volume grande de dados contíguos do disco, o que ocorre muito raramente na maior parte dos programas. Você tem que pensar na largura de banda para evitar partes conflitantes, porque (é claro) a largura de banda mais baixa utilizável é um cano que restringe tudo o mais.
Eu vou ignorar IDE. IDE não presta para sistemas multi-processados, ponto final. Você pode usar um CDROM IDE, se você não se importa com sua performance, mas se você se importa com isto, escolha SCSI. (Cuidado, se você misturar um CDROM IDE com dispositivos SCSI em sistemas GNU/Linux, você terá que rodar uma camada de emulação que é pouco confiável.)
Vamos então examinar os discos primeiro. Sempre que você estudar um disco seriamente, leia suas especificações técnicas. Todo fabricante que se preze publica estes dados em seu website; leia o código do produto e siga as setas. Cuidado com números ("<12ms fast!") que você ver em anúncios; estes caras frequentemente olham os números mais altos/baixos e os colam nos anúncios. Não é desonesto (normalmente), mas ignorante.
O que você precisa descobrir sobre um disco é:
fiber (isto é uma camada física especial que não é apropriada para computadores de pequeno porte). Você frequentemente encontrará o mesmo disco com interfaces diferentes.
Estes números possibilitarão que você faça uma comparação correta entre discos. Um alerta, eles irão difererir em modelos de tamanho diferente do mesmo disco; tipicamente, discos maiores terão tempos de busca (seek time) mais lentos.
Bem, o que significa tudo isto? Largura de banda primeira: a taxa de transferência de dados é o total de dados, em condições ideais, que você consegue extrair do disco por segundo. Este valor é principalmente uma função da velocidade de rotação; quanto mais rápido o disco rodar, mais dados passam por segundo sob as cabeças de leitura e gravação. Isto limita a largura de banda sustentada deste disco.
Mais interessante ainda, a latência efetiva é a soma do tempo de busca típico e da latencia rotacional. Então, para um disco cujo tempo de busca seja de 8.5 ms e 4ms de latência rotacional, você pode ter que esperar cerca de 12.5 ms entre o momento em que o disco "quer" ler seus dados e o momento em que ele efetivamente começa a lê-los. Este é o número que você quer que seja o menor possível. Então, estamos procurando por um disco com tempo de busca baixo e altas taxas de rotação (RPM).
Para efeito de comparação, o primeiro disco que eu comprei era uma unidade com capacidade de 20 MB, um tempo de busca de 65 ms, e cerca de 3.000 RPM. Um disquete tem um tempo de busca entre 100 e 200 ms. Um CDROM tem um tempo de busca entre 120 ms (rápido) e 400 ms (lento). Os melhores discos IDE tem um tempo de busca entre 10 e 12 ms e 5.400 RPM. O melhor disco SCSI que eu conheço (Fujitsu MAM) funciona com 3.9 ms/15.000 RPM.
Discos rápidos e grandes são caros. Discos realmente grande são muito caros. Discos realmente rápidos são bastante caros. Por outro lado, discos muito lentos e pequenos são baratos, mas não são efetivos em termos de custo, porque não custa menos fazer as carcaças, despachá-las e vendê-las.
Observe que se você precisa de muita capacidade, pode ser melhor comprar dois (ou mais) discos, do que um único disco maior. Pode não apenas ser mais barato, mas você obtém também duas cabeças de leitura e gravação que se movem independemente, o que pode reduzir significativamente o tempo de latência.
Uma vez que você tenha decidido que tipo de disco você quer, você precisa decidir como distribuí-los em um ou mais barramentos SCSI. Sim, você pode querer ter mais de um barramento SCSI. (O meu desktop tem três). Essencialmente, o truque é garantir que todos os discos em um barramento, falando ao mesmo tempo, não excedam a capacidade daquele barramento. No momento atual, eu não posso recomendar outra coisa que naõ seja uma controladora Ultra/wide SCSI. Isto significa que o barramento SCSI pode transferir dados a uma velocidade de até 40MB/s para um disco Ultra/Wide, 20 MB/s para um disco Ultra/narrow, e 10 MB/s para um disco SCSI "rápido". Estes números lhe permitem fazer as contas: um disco de 8 MB/s irá ocupar um barramento inteiro sozinho se for "rápido" (10 MB/s). Três discos ultra/narrow de 6 MB/s cabem em um barramento (3x6=18MB/s<20MB/s), mas por pouco. Dois Cheetahs ultra/wide (12.8MB/s) compartilham um barramento ultra/wide (25.6<40), mas iriam colidir em um barramento ultra/narrow, e qualquer Cheetah teria problemas com a banda de dados em um barramento "rápido" (non-ultra, 12.8 > 10).
Se você acha que precisa de dois barramentos SCSI, você pode optar entre diversas versões populares de muitas controladoras SCSI (inclusive ADAPTEC) que tenham canais duais (dual channel). Estas são simplesmente duas controladoras em uma placa (ocupam apenas um slot PCI). É mais barato e mais compacto do que duas placas; entretanto, em algumas placas mãe com mais do que três slots PCI, usar duas placas pode ser mais rápido (perguntem-me o que é uma ponte (bridge) PCI :-).
A performance SCSI pode às vezes ser melhorada definindo o ID do disco usado com mais frequencia com um valor tão alto quanto possível. A ordem de prioridade é tal que dispositivos com IDs mais altos recebem prioridade no barramento quando a arbitragem ocorre durante a fase de seleção.
Como lidar com dispositos SCSI lentos: CD-ROMs, scanners, unidades de fita, etc.? Se você plugar estes dispositivos em um barramento SCSI com discos rápidos, você irá tornar as coisas um pouco mais lentas. Você pode ou aceitar que (como em "Eu quase nunca uso meu scanner"), ou ligá-los em um barramento SCSI separado ligado a uma controladora barata. Ou você pode tentar obter uma versão ATA para ligar naquela inevitável interface ATA da sua placa mãe. A mesma lógica se aplica a discos que você não irá usar com frequencia, tais como discos removíveis para troca de dados.
Se você se encontra na faixa mais alta do jogo da largura de banda, saiba que a capacidade máxima teórica do barramento PCI é 132MB/s. Isto significa que uma controladora SCSI dual ultra/wide (2x40MB/s) pode ocupar mais da metade da largura de banda do barramento PCI, e não é aconselhável adicionar outra controladora rápida a esta configuração. Sendo assim, é melhor que o seu driver de dispositivo esteja bem escrito, ou então o seu sistema inteiro vai derreter (falando figurativamente).
A propósito, todos os números que eu usei são números de largura de banda "ótimos". Na prática, os valores reais ficam entre 50 a 70% do valor nominal, mas as coisas tendem a se anular - os drives não transferem tão rápido quanto poderiam, mas o barramento SCSI também tem um overhead, assim como a placa controladora.
Se você tem um único disco ou vários, em um ou muitos barramentos SCSI, você deve dedicar muito atenção ao particionamento de seus discos. Dado um conjunto de discos e controladoras, esta é a decisão mais crucial a respeito do desempenho que você terá que tomar.
Uma partição é um grupo de setores contíguos no disco. O particionamento começa tipicamente de fora e continua para dentro. Todas as partições em um disco compartilham uma única cabeça de leitura e gravação. Isto significa que se você tentar sobrepor I/O na primeira e última partição do disco, as cabeças precisam se mover rapidamente para a frente e para trás sobre o disco, o que pode aumentar radicalmente o atraso nas operações de busca. Uma partição que esteja no meio de uma pilha de partições provavelmente terá um desempenho de busca melhor, pois no pior caso, as cabeças de leitura e gravação terão que se mover apenas até a metade do caminho para chegar aos dados (e provavelmente elas estarão por lá mesmo).
Sempre que possível, coloque as partições que competem umas com as outras em discos diferentes. Por exemplo, /usr e a partição de swap devem ficar em discos diferentes sempre que possível (a menos que você possua quantidades indecentes de memória RAM).
Outro problema é que a maior parte dos discos modernos usam setorização por zona (zone sectoring). A vantagem é que as partições mais externas terão uma banda maior do que as partições mais internas (existem mais dados por rotação sob as cabeças). Então, se você precisa de uma área de trabalho para streaming de dados (p. ex., uma pré-imagem de um CD-R para ser gravada), ela deve ficar em uma partição na área externa (numeração mais baixa) de um disco de rotação rápida. Da mesma forma, é uma boa convenção colocar partições raramente usadas, cujo desempenho não seja crítico, em partições mais internas (últimas).
Uma outra observação diz respeito ao modo de páginas SCSI. Cada disco SCSI moderno tem uma pequena parte de seu disco (ou uma EEPROM dedicada) reservada para informação de configuração persistente. Estes parâmetros são chamados mode pages, para o mecanismo (no protocolo SCSI) para acesso a eles. Estes parâmetros determinam, entre outras coisas, como o disco irá fazer o cache de gravação, que formas de recuperação de erros ele usa, como seu cache de RAM é organizado, etc. Muito poucos utilitários de configuração permitem acesso aos parâmetros de modo de página (eu uso o FWB Toolkit em um Mac - é simplesmente a melhor ferramenta que eu conheço para esta tarefa), e as configuração normalmente são pré-definidas na fábrica para, ah, ambientes windows 95 com hardware marginal e operação mono-usuário. Particularmente, a organização do cache e as páginas disconnect/reconnect podem significar uma diferença tremenda na performance real. Infelizmente, na verdade não existe lanche grátis aqui - se você define os parâmetros erroneamente, você pode corromper os seus dados de uma forma que você não irá notar senão meses depois, então isto definitivamente não é algo para se brincar mudando parâmetros para ver no que dá.
Ah, sim, caches. Existem três pontos principals em que você pode fazer cache de buffers de I/O: o sistema operacional, a controladora SCSI, e a controladora do disco. Cache inteligente do sistema operacional representa, de longe, o melhor ganho, e por muitas razões. Caches de RAM na controladora SCSI são praticamente inúteis nos dias de hoje; você não deve pagar mais por eles, e experimente desabilitá-los se você gosta de experimentar.
Cache de RAM nos discos é um recurso de duas faces. Com um tamanho moderado (1 a 2 MB), eles são um grande ganho potencial para sistemas Windows 95/98, devido à implementação estúpida da memória virtual e dos drivers de I/O. Se você roda um sistema realmente multi-tarefa como GNU/Linux, ter caches de RAM unificados no disco é uma perda significativa, pois threads de I/O sobrepostas se põem para fora do cache umas às outras, e o disco acaba trabalhando para nada.
A maior parte dos discos de alto desempenho pode ser reconfigurada para ter caches segmentados (algo como um conjunto associativo de cache de memória). Com este recurso configurado propriamente, os caches de RAM podem representar um ganho moderado, não porque o cache de disco é tão fantástico (é muito melhor no sistema operacional), mas porque permite que a controladora de discos tenha mais flexibilidade para replanejar a sua fila de pedidos de I/O. Você não irá notar algo a não ser que você tenha, rotineiramente, mais do que dois pedidos de I/O pendentes ao nivel do SCSI. A sabedoria tradicional (tente de ambas as formas) se aplica.
Finalmente, eu tenho que acrescentar uma nota de isenção de responsabilidade. Muito do que foi dito acima é uma simplificação desavergonhada. Na realidade, discos SCSI de alto desempenho são umas bestas muito complicadas. Eles rodam mini sistemas operacionais que funcionam melhor se possuem 10 a 20 pedidos pendentes ao mesmo tempo. Sob estas circunstâncias, as latências globais amortizadas são muito reduzidas, embora qualquer pedido único possa obter latencias mais longas do que se houvesse apenas uma operação pendente. As únicas análises realmente válidas são modelos de processos estocásticos, que é algo que realmente não desejamos abordar aqui.
This policy contains information about your privacy. By posting, you are declaring that you understand this policy:
This policy is subject to change at any time and without notice.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
Comentários