?

Log in

No account? Create an account
ЖЖ-логия: опять проблемы - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

ЖЖ-логия: опять проблемы [ноя. 4, 2001|01:34 pm]
Anatoly Vorobey
[Настроение |frustratedfrustrated]

Комменты не работают, ага. И вообще все страницы, кончающиеся на .bml. А всё остальное работает вроде.

Всё, без запасного администратора где-нибудь в европейских часовых зонах нельзя больше жить. Постараюсь изо всех сил Брада в этом убедить, когда он проснётся.

P.S. Прогноз такой: комменты не будут работать примерно следующие 7 часов. Потом заработает всё.
СсылкаОтветить

Comments:
[User Picture]From: jsn
2001-11-04 11:20 am
У меня к Вам вопрос, как к человеку близкому к LJ core team.
Все эти меры с дежурными админами и дополнительными серверами, по-моему, только растягивают агонию. Мне кажется, разумным выходом был бы переход к сильно распределенной схеме -- действие, аналогичное тому, которое привело древние чатсервера к превращению в irc-сети.
Вопрос, собственно, такой -- core team эту идею вообще рассматривает?
(Ответить) (Thread)
[User Picture]From: a48
2001-11-04 01:09 pm
btw, вот mdh уже ставит у себя код LJ на отдельной машине. возможно, стоит попробовать обсудить это все применительно к? ведь, просто так комьюнити перетащить не очень реально, а если это будеть "сеть" - то как раз наоборот.
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 01:18 pm
что значит -- будет сеть? на существующем движке никакой сети не будет, насколько я понимаю.
(Ответить) (Parent) (Thread)
[User Picture]From: avva
2001-11-04 01:45 pm
Возможность построения сети всегда имеется в виду. В данный момент над этим в коде, насколько мне известно, никто не работает, но все архитектурные изменения эту необходимость учитывают, и рано или поздно над этим работать начнут. Я уже спрашивал как-то у Брада, что делать со всякими нетривиальными проблемами, типа namespace clash, cross-server friends и т.п., и он тогда ответил, что всё это уже обдумывалось и решаемо.
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 02:20 pm
Как-то я почти уверен, что оно не будет распределенно жить на существующем движке. Все-таки очень много есть вещей, которые лучше бы учитывать в самом начале разработки -- и которые в этом проекте, в силу очевидных причин, учтены не были. Задача действительно очень сильно поменялась с тех пор, как они начали, так что, по-моему, лучше переписать сейчас.
(Ответить) (Parent) (Thread)
[User Picture]From: a48
2001-11-04 09:30 pm
я-то как раз подразумевал изменение движка с тестовым мдхашным сервером, но вы тут уже это вовсю обсуждаете :)
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: jsn
2001-11-04 01:35 pm
да я с самого начала думал, что идея местами сильно порочная. собственно, в первый же момент, когда начались проблемы с производительностью и стабильностью (летом?), надо было бросать добавление новых фич и все переделывать под реальную жизнь. такой сервис в принципе может прилично выжить только в одном из двух вариантов -- если им владеет кто-то вроде AOL или MS, или если он полностью распределен, как irc network.
(Ответить) (Parent) (Thread)
[User Picture]From: bradfitz
2001-11-04 01:36 pm
We are thinking about & working on making distributd LiveJournal servers work together. That's been a goal for awhile.
(Ответить) (Parent) (Thread)
[User Picture]From: avva
2001-11-04 01:37 pm

Re:

Heh, you spared me an answer ;)
(Ответить) (Parent) (Thread)
[User Picture]From: bradfitz
2001-11-04 01:39 pm
I was counting on you translating. :-)
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 02:13 pm
IMHO, the only way to accomplish this task is to do what irc people did.
I mean, it probably makes sense to go public, and to develop kinda open standard or something, at least for the network protocols in use. I also suppose it will require a complete redesign of the engine, like from scratch. And i think that the best way to develop this new engine is to go public either. From what i can
see, the existing livejournal development team is busy enough just keeping the thing alive. Thus, to build an open development community seems to be the only option.
My suggestion is to create some sort of discussion group where we could work out the specification for the new engine and the protocols, and then, when the specs are basically ready, we could just use the usual open source development model -- contributors, committers, etc.
Why not right now, I mean. LJ is already quite unstable and unreliable, and i'm afraid it's gonna be only worse.
(Ответить) (Parent) (Thread)
[User Picture]From: avva
2001-11-04 02:27 pm

Re:

Uhm, all LJ code and protocols are already public, open source actually. And there's a community - lj_dev and mailing lists (http://lists.livejournal.com) for just that sort of thing. There *is* an open development community, it's just rather small, but that's because simply not enough people come and contribute.
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 02:36 pm
I know, i know. But people in lj_dev community mostly deal with the existing engine and maintenance problems. I'm afraid we need another one. The existing engine and the maintenance problems are not going away. In fact, i suppose we are going to see even more existing engine and maintenance issues in the nearest future.
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 04:33 pm
There *is* an open development community, it's just rather small, but that's because simply not enough people come and contribute.

I'm willing to come and contribute, at least to the issue mentioned above -- because i don't see how the project is going to survive without some really comprehensive distributed processing capability. For me, the main question is the core team policy about the issue. I can do my best to design server-to-server protocols and new engine architecture, but what is the core team opinion about it? If they are not going to implement these protocols, protocols are useless. If they are not going to comment real heavy on the supposed protocol specifications and new engine architecture, it's mostly useless too. If, for example, they are not going to split current or future user base between the existing servers and the new remote ones, the whole idea of new protocols/engines is absolutely useless.
That's why i'm asking, and that's, generally, what i'm asking about. What do you, guys, think about it? Please.

(Ответить) (Parent) (Thread)
[User Picture]From: avva
2001-11-04 04:48 pm
Hmmm.

Can you present more clearly your vision of what a distributed platform means, in context of LJ?

Let's try to keep separate two different applications of distribution, so as to avoid confusion (as I've been trying to do in our philosophical discussions, and I apologise, BTW, for neglecting them somewhat during the last few days ;)):

1. Distribution to lighten the load off servers.
2. Distribution to enable very different kinds of LJ-code-based entities to interoperate.

What's different is the intent: in the first case the intent is to allow the main LJ site to grow, in the second it's to allow all kinds of LJ-code-based sites (not affiliated with lj.com, just using the open-source LJ code) to interoperate, use each other's users in friends views, etc.

The second kind is what Brad and I were talking about. You seem to focus on the first kind, I think: complete distribution and independence of LJ servers from each other is necessary to survival of LJ, in your opinion.

It may be true, but I don't see that as self-evident, currently. As you probably know, LJ *is* employing a lot of distribution currently, distributing database access over many servers and web access over many more servers. It's true that this distribution is not complete, i.e. there's a single database and there's a master machine holding all of it. But the master machine is not a bottleneck and historically hasn't been; almost all the problems LJ faced were *not* due to traffic or access bottleneck on the master machine. They were usually over replication issues, or web slave failures, etc.; stuff that can fail just as well if you have completely independent servers (since they still will have to replicate/share information, and web servers will still fail sometimes or be overloaded).

So, can you be more specific about what you see as necessary, in light of the above?
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 05:32 pm
I apologise, BTW, for neglecting them somewhat during the last few days ;)

Tew, nevermind :) That's always very interesting but rarely deadly urgent.

1. Distribution to lighten the load off servers.
2. Distribution to enable very different kinds of LJ-code-based entities to interoperate.

...
You seem to focus on the first kind, I think: complete distribution and independence of LJ servers from each other is necessary to survival of LJ, in your opinion.

That's right, that's what i think.

It may be true, but I don't see that as self-evident, currently. As you probably know, LJ *is* employing a lot of distribution currently, distributing database access over many servers and web access over many more servers.

Yeah, i know that.

But the master machine is not a bottleneck and historically hasn't been; almost all the problems LJ faced were *not* due to traffic or access bottleneck on the master machine. They were usually over replication issues, or web slave failures, etc.; stuff that can fail just as well if you have completely independent servers (since they still will have to replicate/share information, and web servers will still fail
sometimes or be overloaded).


You already have probably tens of boxes running web frontends, right? If the things are going to develop the way they currently do, master machine will eventually become a bottleneck. The same tendency about traffic and everything. I mean, on the long enought time scale every singularity (like master server) will become a bottle neck.
Actually, i think that webslave failures also mean a bottleneck of some special kind: there probably *too many* webslaves, and thus they are harder to control perfectly. If, in other hand, we could have a bunch of relatively independent serving locations, under different authorities and stuff, each of these (smaller) locations would be much easier to control and maintain.
Probably i also should mention another kind of bottleneck situation: like a power failure or even planned maintenance procedures.
(Ответить) (Parent) (Thread)
[User Picture]From: jsn
2001-11-04 10:37 pm
BTW, could you please provide me with a description of the current technical LJ problems? I read lj_dev and lj_maintenance for a while, but probably failed to extract much of internals. Obvious guess would be:
1. Slave mysql servers are unstable under the heavy load of sql requests ("select"s).
2. Frontend webservers run out of cpu || ram || maxproc || file descriptors while parsing sql replies and processing templates.
(Ответить) (Parent) (Thread)