On Sâm, sept. 26, 2015 at 7:47 a.m., Petru Rațiu <rpe...@gmail.com> wrote: 2015-09-26 0:57 GMT+03:00 Dumitru Ciobarcianu <dumitru.ciobarci...@ines.ro>:
> > Salut, > > Am avut o provocare interesantă săptămâna asta și sunt curios cum ar fi > rezolvat-o alții (there is more than one way to skin a cat). > > Se dă o listă de job-uri care se dorește a fi executată. Pentru că > mașina este relativ puternică și se dorește a se scurta durata de > execuție (wall clock) job-urile se pot paraleliza. Pentru că oricât de > puternică este mașina nu are rost să pornești sute de procese în paralel > se dorește ca doar un număr N de job-uri să se execute simultan. Pentru > că fiecare job are o durată variabilă a execuției se dorește ca în > momentul în care un job se termină altul să pornească în loc astfel > încât la fiecare moment dat să existe N joburi rulând în paralel. > > A se rezolva în shell. > IMHO, ambitii gen 'trebuie scris in shell' duc la redneck sysadmin scripts si se justifica doar daca era one-off si n-ai avut timp sa te gandesti la ceva mai elegant. Eu am avut challenge-ul descris mai sus in mai multe forme, si in functie de cat timp am avut la dispozitie si cat de robusta s-a vrut sa fie solutia am folosit diverse abordari: * La problema: "vrem de exact N ori acelasi command line, cand termina unul sa porneasca altul la fel" am rezolvat-o cu supervisord sau cu Parallel::ForkManager din perl. * La problema: "vrem sa facem chestiile astea in paralel si sa asteptam pana termina cea mai slow" am pus GNU parallel (cred ca se putea folosi si la aia dinainte). * La problema " vrem sa apelam programul X cu parametri e la 1 la 10000 si sa ruleze pe N threaduri, potential pe masini diferite" am facut o inginerie cu counterul ala fiind format din fisiere pe nfs pe care obtineam lock cu rm (care e dragut si se executa atomic). Au fost pornite varii instante ale buclei cu pricina pe diverse masini si ne-am uitat dimineata sa vedem ca a terminat. Daca aveam ceva mai mult timp faceam counterul ala in mongo sau mysql, da' a evoluat organic un oneliner in chestia asta. La cum ai formulat problema, presimt ca vrei sa vezi monstrul de la punctul 3, da' nu e nimic de lauda (poate doar ca demonstratie la "distributed locks are hard, mmkay?"). ====== Cred ca pointul problemei era sa vada examinatorul abilitatile de scris algoritmi ale sysadminului si nu atingerea unui scop indiferent de metoda. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
