Comparativo: Upstart X systemd X SysVinit X OpenRC
Enviado por Pablo Hess (pabloΘhess·net·br):
“Foi com base em um comentário aqui do BR-Linux que eu escrevi este post no IBM developerWorks comparando 4 sistemas de init: Upstart, systemd, SysVinit e o desconhecido OpenRC.
A conclusão é bem óbvia: se você não quer se arriscar, fique com a solução nativa oferecida pela sua distribuição. Porém, creio que vale como estudo de métodos alternativos de inicializar um sistema, ou ainda caso você esteja considerando mudar seu sistema de init atual.
Ah, e já adianto: não fiz nenhuma comparação de desempenho porque precisaria implementar cada um dos 4 sistemas de init em uma única distribuição iniciando os mesmos serviços, e isto é impraticável. Se alguém discordar, fique à vontade para sugerir uma metodologia, que eu aplicarei com felicidade. :)” [referência: ]
• Publicado por Augusto Campos em
2011-03-31
@brlinuxblog
Feed RSS
Excelente artigo, vale ir pra lista de referências.
Só frustra a frase do final: “Se você precisa de um sistema de init estável, não há dúvida: fique com aquele que a sua distribuição oferece por padrão. :-)”
É um recado sensato e era uma conclusão esperada, mas frustrante, devido a fragmentação. Eu me importo mais com facilidade de configuração e uso, no caso criar e manter scripts, que a velocidade.
Gosto muito do que oferece o Upstart e estou bem contente com o desempenho ao iniciar no ubuntu (Kubuntu 10.04).
Pelo artigo, ainda fiquei com impressão que talvez o melhor fosse fazer o merge dele com Systemd.
Mecanismo de alta paralelização do Systemd com a forma de configurar do Upstart.
Weber: por que você precisa da forma de configurar do upstart? Se você quer simplesmente subir um daemon/serviço, não precisa escrever nenhuma linha de código C.
O arquivo de configuração para criar serviços no systemd é tão ou mais simples que o upstart. Além disso, isso é feito mantenedores da distribuição em conjunto com os dos pacotes separados.
Lucas
Eu estou me referindo a quem desenvolve um serviço/daemon e então parte para criar o script de inicialização. Não somente usar, para usuário realmente só importa velocidade de boot.
Eu achei mais simples, ou mais claro, os arquivos de configuração do Upstart. Mas nada de outro mundo de complicado o Systemd.
E com a ressalva de que o Upstart eu já havia lido a respeito muito mais que a única que li sobre o Systemd, no artigo do Pablo. Então pode ser somente a velha conhecida resistência ao novo.
Eu ainda acho o SysV a melhor opção, e é uma pena que nenhuma grande distribuição o utilize mais. O upstart, systemd e outros são uma solução para um não-problema, iniciar tudo em paralelo dificulta achar problemas quando coisas dão errado, e ainda por cima quebram compatibilidade com décadas de documentação.
O SysV funciona, e é “rock-solid” por anos de utilização, tem uma implementação elegante e é fácil de configurar. O upstart é uma zona na implementação, espalhando os arquivos de configuração em meia dúzia de diretórios sabe-se lá pra quê.
Mas aparentemente se vc não é um mané com um netbook num wifi precisando iniciar “super rápido” pra ver seu twitter vc não é mais relevante então as distros todas estão chupando do ubuntu agora.
Tá na hora de eu seguir os tutoriais do LFS denovo e manter uma “distro de um usuário só”.
Hess, o artigo foi sucinto e direto ao ponto. Só vou fazer uma observação: achei q
(droga, dei ENTER sem querer)
Hess, o artigo foi sucinto e claro (direto ao ponto ficou redundante). Só vou fazer uma observação: achei que o OpenRC fosse usado também no OpenBSD (ledo engano).
Os novos scripts que tenho feito são exclusivamente para uso no Upstart, mas agora fiquei inclinado a testar o systemd.
Particularmente acho que os sistemas atuais demoram muito para iniciar. Copiar 4GB de dados do disco para a memória é um processo rápido (fácil de calcular por ter uma métrica definida), como podemos ver no processo de “hibernar”, que demora poucos ou mesmo só um segundo. Mas iniciar um sistema do zero, que em teoria é copiar coisas do disco pra memória, é um processo demorado, que efetua milhares de passos.
O kernel em si carrega bastante rápido, por ser algo “atomico”, ou seja, carregar kernel e pronto. Ai já entram os vários módulos: o sistema realiza dezenas de passos para determinar se um módulo precisa ser carregado. Em vários sistemas esta quantidade de checagem não é necessária. Ou seja, cada arquivo é um seek, espera do cabeçote do HD no lugar certo, verificação de outras tantas coisas…
Aí entrem os scripts pra checagem de serviço, que implementam de manera extremamente ineficiente coisas que poderiam ser implementadas numa aplicação que utilize uma linguagem rápida, sem muitos acessos em disco. Na verdade que seja só um acesso, para o carregamento do interpretador ou do executável do programa.
Uma maneira de otimizar o processo, ao meu ver: armazenar todas as informações sobre daemons, módulos, etc. numa estrutura otimizada para armazenar dados: bancos de dados (não sgbds). Há vários que fazem isso; sqlite, hammerdb, eet (uma especie de banco de dados baseado em chave/valor), etc. Pronto, problemas de desempenho no acesso à disco para ler configurações resolvido.
Com isso, o único custo extra no acesso ao disco seria o de carregar os módulos do kernel, carregar os executáveis dos daemons e jogar cada chamada system(“my_daemon -d”) numa thread diferente e seguir em dianta. Sei lá, alguma coisa assim.
@tenchi
A cópia dos dados da memória pro HD ao hibernar não inclui TODA a memória usada. Buffers e cache geralmente ficam de fora, o que já deixa o volume BEM menor que o tamanho total da sua memória física. Além disso, a cópia dos dados do disco pra memória ao retornar da hibernação não é tão rápida assim: sempre demora vários segundos num laptop Core i5 com 4 GB de RAM. O que é rápido mesmo é a suspensão para memória, e justamente porque usa a RAM — não o lento HD.
Sobre a aceleração do boot, o que mais demora não é carregar as configurações dos serviços, mas o fato de alguns deles precisarem que outros sejam completamente iniciados para então poderem iniciar. Então, imagino que armazenar as configurações num banco de dados simples não ganharia desempenho de boot. E o próprio kernel demora para ser carregado e “fazer o que tem que fazer”: no mesmo laptop com um Core i5 e 4 GB de RAM, o kernel leva 4 segundos e pouco para “entregar o bastão” ao init.
Por último, simplesmente iniciar todos os serviços em background não é uma solução viável. Se o serviço XYZ precisar do ABC para subir e ABC não estiver iniciado, o XYZ será incapaz de iniciar (em segundo plano ou primeiro plano). É preciso ter ordem.
A sua sugestão, na minha opinião, é próxima à abordagem do systemd: iniciar todos os serviços de uma vez e fazer com que se comuniquem entre si via sockets e pipes (em resumo, via D-Bus). Com isso, ele consegue justamente o objetivo de iniciar tudo e ainda assim manter a ordem. No exemplo de XYZ que depende de ABC, o XYZ iniciaria junto com o ABC, e enviaria ao socket do ABC suas requisições. Quando ABC terminasse de subir, ele processaria as requisições e retornaria eventuais resultados a XYZ. Ou seja, todos iniciam juntos (ou o mais próximo possível disso) sem que ninguém sofra.