| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Porque é que um projecto Português tem um nome inglês? (Uptime)
Porque me soa mal "Está em cima" ou "Está de pé"
Achei piada a esta entrada na faq.
Gustavo Felisberto
72ef1d7183eb2ea89420b94c0cf3e1f1
apt-get install anarchism |
| |
| por Anonimo Cobarde em 08-06-02 12:55 GMT (#2)
|
| Epa tem de me explicar porque é que é bom ter grandes uptimes e sem manutenção. Isso não quer dizer nada nem mede a estabilidade de nada.
A unica coisa que nos diz é que o computador pode estar vulneravel porque não aplicou os security patches no kernel ou que o admin é um preguiçoso do caraças.
P.S. Já agora tambem podem participar "failover" clusters ?
|
| |
| |
| por Anonimo Cobarde em 08-06-02 17:47 GMT (#4)
|
| Interessante tambem e' saber se essas maquinas estao a fazer alguma coisa. Sim, porque meter uma maquina num canto sem fazer nada, tirando falhas a nivel de hardware, pode muito facilmente levar a uptimes gigantes..
|
| |
| | hummm... não concordo com:
"A unica coisa que nos diz é que o computador pode estar vulneravel porque não aplicou os security patches no kernel ou que o admin é um preguiçoso do caraças."
Um bom uptime não implica nada disso.
As falhas de segurança + vulgares não são no kernel. Uma máquina só deve ser posta em produção quando está pronta - supostamente segura.
Um bom uptime implica ter sempre serviços sempre disponiveis - o conhecido "twenty four x seven".
Outra coisa de louvar é o trabalho que permite alterações sem reboot
"Big brother is watching you, and little brother is too. When big brother goes to sleep, little brother goes through his stuff." |
| |
| | Por acaso *deixa*.
E no caso de máquinas com certo tipo de arrays scsi, pode demorar bem mais do que 2 minutos...
"We have no choice! Our Communist overlords will slay us if we fail in our mission!"
- A chinese military officer, "Tales of Suspense" #50, 1964 |
| |
| | Será que já alguem ouviu falar no conceito de "Redundância"?
Em qualquer mecanismo que seja vital estar sempre disponível parece que o melhor método de o assegurar é havendo redundância, seja a que nível for.
Estas coisas dos uptimes faz-me lembrar aquela história... "a minha é maior que a tua".
Cumprimentos,
Bruno Gravato.
|
| |
| | | Quer dizer que, já que há redundância então agora passar a vida a desligar as máquinas, passou a ser uma coisa boa! Acho que vais ter que te esforçar para convencer alguêm disso!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| |
| | | Eu nunca falei em "passar a vida a desligar as máquinas". Apenas disse que era bom ter redundância na eventualidade de algo anormal, acidental e/ou inesperado acontecer...
ilusão, do Lat. illusione
s. f.,
engano dos sentidos ou da inteligência;
errada interpretação de um facto;
pensamento quimérico;
(...) Cumprimentos,
Bruno Gravato.
|
| |
| | Mouse engenier detector has been activated! Please protect your reboot button!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
| |
| | Para os maniacos do último kernel, aqui está um artigo simpático sobre como software antigo pode contribuir para a segurança.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| por Anonimo Cobarde em 08-06-02 14:02 GMT (#3)
|
| Que tal o nome: "Sempre-em-pé" ???
E uptimes de routers, tambem contam??? ;-)
CF
|
| |
| | 5:32am up 7 days, 7:05, 5 users
quem olhar para este uptime vai pensar que é de um win32, mas não...
esta máquina já "deu a volta"...
deve ter quase 2 anos de uptime. --> Uma boa razão para não participar nisto... :) ...ia aparecer em ultimo embora não seja bem assim!
falando nisto... alguém sabe de uma boa maneira para determinar o uptime de uma máquina que já "deu a volta"?
Regards,
Nuno Silva aka RaTao |
| |
| |
| | | o linux da' a volta aos 498 dias; esse problema foi removido no final da serie 2.4, se n me engano; serao horas de dar cabo do uptime? :-) Cheers,
Luis Bruno
Cheers,
Luis Bruno |
| |
| | Exactamente!
Por acaso eu faço reboots sempre que posso, mas no caso destas máquinas (sim, é mais do que uma com este uptime...):
- não posso (não adianta explicar...) ;
- não preciso (!) ;
- esta máquina tem um 2.2.18 que, como se pode ver, é muito estavel e lá por ser da série 2.2 não quer dizer que tenha "um kernel antigo cheio de bugs".
Outro facto interessante: falei em linux32 por alguma razão!! =)
Esta máquina,
cpu : Alpha
cpu model : EV6
que pertence ao mesmo cluster tem um uptime que não dá a volta: 9:27am up 503 days, 5:55
Vivam os processadores 64bits!! =)
Conclusão: quem quiser participar numa coisa destas que use máquinas alpha ou sparcs ehehehe
Regards,
Nuno Silva aka RaTao |
| |
| | Podes sempre alterar o source do programa cliente para lhe somares o tempo que falta a esse uptime...
No fundo, não é batota... É o uptime real da máquina...
[update]
Aliás, nem é preciso alterar mo código. O cliente que é recomendado na página do PTNix tem um define que diz o seguinte:
<quote>
Linux users: If you are the proud owner of a Linux box, but your uptime wraps around after 497.1026963 days, you can define here how many times that cruel thing happened to your box.
</quote>
Cumps, sena.
--
sena@smux.net
http://sena.u.smux.net/ |
| |
| | Eu acho uma piada aos vossos posts k nem vos digo.. qdo alguem tenta fazer alguma coisa para melhorar ou para por o pessoal a participar e' so' critícas, mas ñ fazem nada para melhorar isso.. é mesmo a Tuga! participem nisso e vejam lá se estão kalados que fazem melhor figura e já agora mostrem os nicks dos posts ou são cobardes? ao menos há algum projecto para incentivar o ppl a fazer qualquer coisa.. Xau []
|
| |
| |
| | Yeah, chamem-lhe nomes agora.. ursos!
|
| |
| | | Nao será o caso de "a reboot a day keeps the doctor away". Mas posso dizer que sempre foi minha politica fazer um reboot semanal a qualquer maquina que administro; ou um reboot mensal no caso de maquinas mais "estaticas". Um reboot regular resolve uma serie de problemas (memoria fragmentada, memoria nao libertada, tabelas de sistema corrompidas,etc) que podem nao "aparecer" mas que causam "gremlins" a medio prazo. Os uptimes são como as pilas: há quem as tenha mais compridas mas com mais smegma, menos banho e portanto menos uso. Cumprimentos Mario Valente
|
| |
| |
| por Anonimo Cobarde em 10-06-02 22:05 GMT (#25)
|
|
Nao será o caso de "a reboot a day keeps the doctor away". Mas posso dizer que sempre foi minha politica fazer um reboot semanal a qualquer maquina que administro; ou um reboot mensal no caso de maquinas mais "estaticas".
Um reboot regular resolve uma serie de problemas (memoria fragmentada, memoria nao libertada, tabelas de sistema corrompidas,etc) que podem nao "aparecer" mas que causam "gremlins" a medio prazo.
What? Isto e' a coisa mais ridicula que ouvi nos 'ultimos tempos! Experimenta comecar a usar SO's que tenham uma nocao minima do que e' VM management, e aplicacoes que nao sao codadas numa backroom-rice-factory-type-shack-somewhere-in-east-asia e que sabem libertar a memoria depois de usarem, e estas coisas deixam de acontecer. Uma aplicacao por si' so' _NAO_ pode matar um SO inteiro. Se isso acontece, algo esta' muito errado! Gostava de saber que SO's e programas usas, devem ser "umas pequenas maravilhas, importadas directamente da tailandia"
Se trabalhasses para mim, ja' estavas despedido ha' muito tempo...
|
| |
|
| | Viva,
Mário, como empresario devias ter mais atenção a parte economica. Há uns tempos li um relatorio de uma empresa que estudou profundamente se devia ou não aumentar a sua largura de banda, se o factor rapidez/lucros lhes era favoravel. O aumento da largura de banda faria que o seu site fosse cerca de 2 segundos mais rapido a carregar(em situação de carga), a conclusao que chegaram é que esses 2 segundos ao fim do ano (tendo em conta PUB e tudo isso)davam uma margem de lucro que nao so pagava a largura de banda a mais como pagava quase na totalidade o custo da linha. Quero eu dizer com isto que o facto de privares os utilizadores todos os dias de acederem ao site cerca de 1 minuto (tempo de um reboot?), no fim do ano terá proporcoes economicas interessantes.
Se todos seguissem essa potilica de reboots, todos os Sistemas Operativos eram equivalentemente estaveis, e o linus, alan cox e companhia nao gastavam horas de programaçao a tentar por a gestao de memoria do linux com a mesma performance de um solaris por exemplo, bastava por no contrab por uma entrada "shutdown -r now" a correr todos os dias. Deve-se fazer um reboot, quando tal o justifica.(Ponto Final)
O projecto não tem como objectivo eleger a maquina mais estavel de Portugal, pois como tu dizes, umas tem muito mais uso que outras e isso nao é contabilizado. È tambem uma forma de saberes que Sistemas Operativos correm no site x ou y, e tentar tirar um elaçao disso, (tipo: a sic tava a correr windows, o que a fez correr em FreeBSD? e porque não OpenBSD? Basicamento penso que foi devido ao OpenBSD não suportar SMP (mas isto é so um exemplo e nao é o que esta em questao).
|
| |
| | Mário, como empresario devias ter mais atenção a parte economica.
Quero eu dizer com isto que o facto de privares os utilizadores todos os dias de acederem ao site cerca de 1 minuto (tempo de um reboot?), no fim do ano terá proporcoes economicas interessantes. Depende em primeiro lugar do custo de 1 minuto de downtime (em Portugal, na maioria dos sites, insignificante); em segundo lugar do facto de um reboot num frontend nao significar necessariamente downtime de um serviço, isto porque existem outros frontends. Se me disseres que existe um site/serviço onde o downtime de 1 minuto é economicamente significativo e NAO TEM mais do que um frontend, desculpa lá mas começo já a rir-me... Cumprimentos Mario Valente
|
| |
| | tipo: a sic tava a correr windows, o que a fez correr em FreeBSD? e porque não OpenBSD? Basicamento penso que foi devido ao OpenBSD não suportar SMP
E pensas muito bem...
PLS
|
| |
| | Ao contrário do Mário eu faço reboots quando tal se justifica. Não mais, não menos. Quando é preciso um novo kernel ou aplicar um patch, quando faço uma substituição das máquinas, quando uma cegonha deixa o país às escuras... :-)
Normalmente há um reboot de 6 em 6 meses nos que correm FreeBSD (em média). No Linux não me recordo da frequência. O uptime não é motivo de "orgulho", mas de constatação de facto: os servidores correm com a estabilidade necessária, quando levam upgrades são rebootados.
Os sistemas são monitorizados e mantidos activamente. Se não há um motivo válido, ou algum sintoma que possa fazer antever tal motivo, os servidores prosseguem o seu trabalho sem qualquer necessidade ou vantagem de ser feito um "reboot".
Concordo com os "gremlins". O garbage colector pode ser menos fiável, o software utilizado pode ter bugs, etc. Mas isso monitoriza-se, estuda-se, e uma vez feita essa monitorização sabe-se exactamente com o que se vive.
O projecto uptimes, tal como o netcraft é engraçado (já o era na versão original). Claro que uma coisa é olhar para servidores que não fazem "népia" e outra completamente diferente é ver servidores que servem "algo" a "alguém". Coloquei alguns servidores "meus" no projecto do ptnix. A "sic" tem três servidores listados (www.sic.pt, programas.siconline.pt e masterplan.sapo.pt), a mrnet tem dois (vogon.mrnet.pt e zealot.mrnet.pt)...
Acho piada ao projecto. Quero participar. Estou-me, obviamente, marimbando para a vertente "competitiva". Até porque não me passa pela cabeça deixar de fazer um reboot sempre que tal se justifique, nem ter servidores para "mostrar uptimes". É ao contrário: estão a ser utilizados (alguns MUITO utilizados), para os mais curiosos figuram na lista (até porque os mais curiosos podiam ir ao netcraft; não é segredo).
Engraçado é ver no netcraft o "www.sic.pt", antes e depois de se ter mudado de Windows para FreeBSD... faz alguma diferença... e antes o site de informação eram 3 máquinas e agora é uma...
PLS
|
| |
| |
| | Concordo com os "gremlins". O garbage colector pode ser menos fiável, o software utilizado pode ter bugs, etc. Mas isso monitoriza-se, estuda-se, e uma vez feita essa monitorização sabe-se exactamente com o que se vive.
Naaah, pode sempre haver memory leaks que não podes monitorizar porque ocorrem em casos especiais, tais como processos que terminam e não libertam por completo a memória alocada.
Claro que quem não quer rebootar de vez em quando (ou quer reduzir a frequência com que acontece) tem de usar software o mais estável possivel e esquecer o bleeding edge, bla, bla, bla...
Mas não, eu não faço reboots regulares, sou um verdadeiro macho :)
--
calço o 40 e uso linux |
| |
| | | Viva! Como já aqui foi discutido, o Uptime não é exactamente uma medida de estabilidade (se tem um uptime elevado provavelmente é estável mas se tem um uptime baixo pode também ser estável: aplicação de patch ao kernel != instável) ou de disponibilidade. Assim sendo se calhar podiam antes tentar fazer uma medida de disponibilidade: soma de uptimes *100 a dividir pelo tempo total desde a primeira recolha de dados. Assim obtinham algo em percentagem e que contabiliza a o tempo de manutenção. Assim podiamos ver que tinhamos uma máquina actualizada com uma disponibilidade de 97% em dois anos, por exemplo. Poderiamos compará-la com uma máquina que tem uma disponibilidade de 100% em dois anos mas está completamente desactualizada. Nessas condições até as máquinas windows poderiam participar. ;) Esta informação já poderia ser mais útil porque contabiliza os downtimes assim como a sua duração. Foi só uma ideia. :) JP
Fiquem bem!
|
| |
| |
| | | Melhor: publiquem a linha toda do "uptime"; incluam os valores de "load average"... Assim é que se podem comparar uptimes de serviços da tanga com maquinas que estao constantemente a rasgar pano... Cumprimentos Mario Valente
|
| |
| | Boa ideia!
E ja' agora informacao do espaco em disco, da memoria usada / disponivel, do numero de utilizadores, das portas abertas, das ligacoes que a maquina tem...
Nao ?...
Cumprimentos,
vd |
| |
| | E eu quase sempre tornei esses valores públicos (raros os casos em que não o faço...).
PLS
|
| |
| | Yeah! Mostrem tambem o diâmetro do animal, não só o comprimento.
--
calço o 40 e uso linux |
| |
