• Здраво и добредојдовте на форумот на IT.mk.

    Доколку сеуште не сте дел од најголемата заедница на ИТ професионалци и ентузијасти во Македонија, можете бесплатно да се - процесот нема да ви одземе повеќе од 2-3 минути, а за полесна регистрација овозможивме и регистрирање со Facebook и Steam.

"Чистење" на "print queue" на Solaris OS

  • Ја почнал/а темата
  • #1

igor_xxxx

Practice makes perfect
10 септември 2010
1,268
1,523
Пред некој ден имав ептен глуп проблем на еден сервер што работи на Solaris OS, вработен по грешка испрати преку 50-60000 копии од еден документ да се печатат на еден принтер и со тоа скоро го блокираше печатењето на сите останати принтери (>120 принтери)

Ме интересира дали може некој да ми каже како би бил најефикасен начин да се "исчисти" print queue-то во ваков случај?

"Стандардниот" начин со "cancel username/printername" во овој случај е далеку од ефикасен зашто му треба долго време (часови) за сите request-и да ги откаже и печатењето е максимално отежнато и забавено.

Се мислев дали би помогнало или дали е можно воопшто на пример да се избришат сите request-и што чекаат во /var/spool/lp и да се рестартира LP Print Scheduler-от или нема врска ова?

Мислење од некој поупатен во оваа проблематика?

Фала многу.
 
  • Ја почнал/а темата
  • #3

igor_xxxx

Practice makes perfect
10 септември 2010
1,268
1,523
Хмм, не ми текна да пробам со queuename, одев со username или printername, мислиш дека времето на извршување со queuename би било побрзо?

Баш ќе пробам утре да симулирам со неколку стотина или повеќе принт фајлови дали ќе има разлика, во двата случаи што јас ги пробав со Cancel процедурата ќе траеше неколку часа.

Дури воопшто не беше можно ни lpstat -o | wc -l да се направи да се види колку фајлови чекаат за принтање.
 
  • Ја почнал/а темата
  • #5

igor_xxxx

Practice makes perfect
10 септември 2010
1,268
1,523
Шо се деси? Проба?
Извини не стигнав вчера да ти одговорам...

Пробав со cancel queuename ама после првиот откажан print request ми крашираше и останатите request-и не беа откажани.После проверка, мислам дека проблемот е со одредени пачови што се инсталирани, затоа што овој баг е напоменат од Oracle за верзијата што е инсталирана на овој систем, ама ова не можам да го сменам.

Потоа тестирав уште еднаш со 3000 копии со две команди, една е Cancel (по user, queuename не може), а друга lpc која што можеше да работи со queuename.

Еве разлика од брзината:

1.Со "Cancel -u username", 3000 копии во queue чекаат, време на почеток и крај:

XXXX:/var/spool/lp/temp % date
Fri Oct 14 11:03:17 CEST 2016
XXXX:/var/spool/lp/temp % date
Fri Oct 14 11:04:05 CEST 2016


2.Со "lpc clean queuename", исто како погоре:

XXXX:/var/spool/lp/temp % date
Fri Oct 14 11:05:45 CEST 2016
XXXX:/var/spool/lp/temp % date
Fri Oct 14 11:05:51 CEST 2016

*Исти резултати беа и кога од 3000 копии, 2000 беа во queue и се стартуваше командата за откажување, LPC скоро инстантно ги откажа копиите што веќе беа испратени, а останатите со повторно повикување ги среди, додека со Cancel исто си требаше време.

Покрај значително побрзите перформанси со lpc, друга разлика што приметив е одма се бришат tеmp фајловите од LP сервисот, додека со Cancel стојат во темп фолдерот, ова ќе прочитам зашто е и дали има некоја улога.Штета што не можам да ги споредам двете команди со исти параметри, Cancel не ми работи со queuename, а LPC нема можност по username, дали големата брзина на LPC е само заради тоа што работи со queuename или не.

Сега уште еднаш ќе направам "реален" тест во неработен ден со LPC, a зависи од резултатот ќе проверам и дали рестарт на принт сервисот ќе помогне или не.Ова беше повеќе да видам дали ќе има некоја разлика и очигледно дека има, е сега како ќе биде со >40-50000 копии ќе видиме.

Фала @FLEGMA за hint-от за queuename, така стигнав до LPC :)
 
Последна промена:

Lokvan

Unbeatable
12 јануари 2016
2,924
4,125
SK
Се извинувам за офтопиков, ама морам да прашам дали е познато како побогу се десило корисникот да испринта 50-60000 копии од еден ист документ??
Никако не можам да му го рекреирам мисловниот процес кога „згрешил“, што му се случувало во главата додека впишувал цифра за принтање на десетици илјади копии и кликнал принт... :)
 

DrMTR

Guru
27 март 2014
6,649
6,642
www.mikrotikmacedonia.net
Се извинувам за офтопиков, ама морам да прашам дали е познато како побогу се десило корисникот да испринта 50-60000 копии од еден ист документ??
Никако не можам да му го рекреирам мисловниот процес кога „згрешил“, што му се случувало во главата додека впишувал цифра за принтање на десетици илјади копии и кликнал принт... :)
Веројатно... :D

[сликата е отстранета заради прекршување на правилата]
 
Изменето од модератор:
  • Ја почнал/а темата
  • #8

igor_xxxx

Practice makes perfect
10 септември 2010
1,268
1,523
Се извинувам за офтопиков, ама морам да прашам дали е познато како побогу се десило корисникот да испринта 50-60000 копии од еден ист документ??
Никако не можам да му го рекреирам мисловниот процес кога „згрешил“, што му се случувало во главата додека впишувал цифра за принтање на десетици илјади копии и кликнал принт... :)
Релативно лесно е да се направи оваа грешка што ја имав.Во конкретниов случај се скенира идент на материјал и се скенира друг баркод со количина што треба да се испечати...ама во брзање и мало невнимание, наместо да се скенира количината, погоди кој петoцифрен баркод е скениран :)

Еднаш морав да рестартирам Windows сервер затоа што беа испратени >1,000,000 копии со иста ваква грешка во Excel.... Мада се сомневам дека и објаснувањето на @DrMTR држи вода, треба да се проверат некои работи :)
 

boriseto

Gaining Experience
7 јули 2013
405
361
Или пак ако паднала мрежата у еден најубавопогоден момент и продолжило да си лупа реквести?
 

Нови мислења

Последни Теми

Статистика

Теми
42,560
Мислења
820,545
Членови
28,218
Најнов член
macika
На врв Дно